w*********a
发帖数: 9279 | |
r********3
发帖数: 2998 | 2 这个还用你说。。。
所以我们面试程序员都说，没有接触过multithread programming的，再牛顶多只能算
中级程序员。
【在 w*********a 的大作中提到】
: 最可怕的bug,是很难重复的bug
|
w*********a
发帖数: 9279 | 3 这年头还有没接触过multithread的程序员？
连初级的都不算
【在 r********3 的大作中提到】
: 这个还用你说。。。
: 所以我们面试程序员都说，没有接触过multithread programming的，再牛顶多只能算
: 中级程序员。
|
r********3
发帖数: 2998 | 4 你问问这个版上做machine learning，computer vision，有几个接触过thread和
process。
相当一部分，连thread和process的概念是什么都不清楚，他们只用matlab。
【在 w*********a 的大作中提到】
: 这年头还有没接触过multithread的程序员？
: 连初级的都不算
|
g*****g
发帖数: 34805 | 5 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
有半个小时一次的thread dump里能看到异常。
Operation team把我老拉近conf room边debug边开会，
客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
是多线程问题，但无法重现。产品环境，log level太高，无充足信息。只好在
核心代码里反复阅读猜测，写测试验证。日夜干了2周没能解决，有天做梦突然
想到某行代码可能有并发问题，侥幸解决。 |
d****n
发帖数: 1637 | 6 赞梦郎。
注意休息啊。
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
|
w***g
发帖数: 5958 | 7 牛啊，谢谢分享
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
|
c****p
发帖数: 6474 | 8 有些问题想得时间长了确实是会在梦里有想法的。
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
|
w**a
发帖数: 4743 | 9 最可怕的一个是系统crash，每crash一次公司赔偿60多万人民币，我接手的时候已经
crash了20多次，整个单子才不到1500万。因为涉及其他厂商联调，必须在产品环境中
debug.. |
N**D
发帖数: 10322 | 10 machine learning, computer vision, 算法有了bug, 查起来也是非常困难的
【在 r********3 的大作中提到】
: 你问问这个版上做machine learning，computer vision，有几个接触过thread和
: process。
: 相当一部分，连thread和process的概念是什么都不清楚，他们只用matlab。
|
|
|
p*********t
发帖数: 2690 | 11 adobe flash会导致手机crash,搞得apple都不用它.現在大部分网站的主页的那个动态
图,很少有用flash的了.
【在 w**a 的大作中提到】
: 最可怕的一个是系统crash，每crash一次公司赔偿60多万人民币，我接手的时候已经
: crash了20多次，整个单子才不到1500万。因为涉及其他厂商联调，必须在产品环境中
: debug..
|
x****n
发帖数: 98 | 12 你这是一秆子打倒一片人,难道做vision/AI/ML的人真这么弱吗?
有些做vision的系统也会作的极其变态,几十个算法都是用c++和java写的,每个有好几
个thread一起运算,运算数据量大,流程又复杂,稍微不注意就会把其他task的内容冲掉,
还要求连续不停机工作至少两周
我遇到的bug比如,系统运行一周后崩溃了,查log追溯最后几个小时,至少几个G的log,但
是log也被冲了一半,最后只能读代码,平均一个算法4千行,挑几个嫌疑最大的先看,写测
试模拟来加快测试,dump系统十几个GB的内存来看,发觉memory fragmented,最后对每一
个算法改写让其更安全,总算在产品phase到期之前测试通过.
【在 r********3 的大作中提到】
: 你问问这个版上做machine learning，computer vision，有几个接触过thread和
: process。
: 相当一部分，连thread和process的概念是什么都不清楚，他们只用matlab。
|
r********3
发帖数: 2998 | 13 没有打倒一片，但是大多数的还是有。你这个都是做到产品级的，当然不一样了。
掉,
【在 x****n 的大作中提到】
: 你这是一秆子打倒一片人,难道做vision/AI/ML的人真这么弱吗?
: 有些做vision的系统也会作的极其变态,几十个算法都是用c++和java写的,每个有好几
: 个thread一起运算,运算数据量大,流程又复杂,稍微不注意就会把其他task的内容冲掉,
: 还要求连续不停机工作至少两周
: 我遇到的bug比如,系统运行一周后崩溃了,查log追溯最后几个小时,至少几个G的log,但
: 是log也被冲了一半,最后只能读代码,平均一个算法4千行,挑几个嫌疑最大的先看,写测
: 试模拟来加快测试,dump系统十几个GB的内存来看,发觉memory fragmented,最后对每一
: 个算法改写让其更安全,总算在产品phase到期之前测试通过.
|
h*i
发帖数: 3446 | 14 This is precisely the kind of problems Clojure is built to solve.
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
|
g*****g
发帖数: 34805 | 15 Clojure is not going anywhere, Scala and the akka stack may be the answer.
Lisp isn't going to be popular, ever. It has to be a C style language
to attract the mass.
【在 h*i 的大作中提到】
: This is precisely the kind of problems Clojure is built to solve.
|
d***q
发帖数: 1119 | 16 clojure 在看,感觉比scala简洁... |
A***o
发帖数: 358 | |
F******k
发帖数: 197 | 18 我来说个实战的例子：
128个线程同时跑在30多个核上，断点极难捕捉。最终确定bug可能是在jitted code中
，虽然截获断点，因为是自己产生的jitted code, caller frame指针被重设，不能回
溯到caller,只能看汇编代码。最终发现产生代码的register allocator在某个特定的
情况下对某个basic block的输入寄存器集合没有更新，导致产生的代码中有个寄存器
没有初始化。
再说个多年前和一个哥们破解一个加密软件。这个软件在并口上插加密卡。当时好像用
的一个叫IDE的巨强大的debug软件。我们连了个示波器到并口上监控哪段代码读并口。
【在 A***o 的大作中提到】
: 看不到输出，驱动，内核什么的代码很难de
|
r********3
发帖数: 2998 | 19 做多线程的调试，要深入到汇编级别看具体那个CPU执行了啥指令，那说明你的整个多
线程运行的环境和测试多没有搭建好。有经验的人，在写多线程的时候，就会考虑到如
何去测试和调试这部分的code。有了这个意念之后，99.999%的问题都可以在你的测试
框架下完成，不用搞到汇编级别去看CPU的操作。另外，你多线程的开发，不应该依靠
断点去调试。
关于系统内核的调试，早几十年别人做单片机和嵌入式设备的时候就很成熟了。一般芯
片都有专门几个引脚来介入调试设备的。专门的调试设备早就有了。
【在 F******k 的大作中提到】
: 我来说个实战的例子：
: 128个线程同时跑在30多个核上，断点极难捕捉。最终确定bug可能是在jitted code中
: ，虽然截获断点，因为是自己产生的jitted code, caller frame指针被重设，不能回
: 溯到caller,只能看汇编代码。最终发现产生代码的register allocator在某个特定的
: 情况下对某个basic block的输入寄存器集合没有更新，导致产生的代码中有个寄存器
: 没有初始化。
: 再说个多年前和一个哥们破解一个加密软件。这个软件在并口上插加密卡。当时好像用
: 的一个叫IDE的巨强大的debug软件。我们连了个示波器到并口上监控哪段代码读并口。
|
F******k
发帖数: 197 | 20 Generally speaking, you are absolutely right. But when you are pioneering
some new system with brand new architecture, the tools and environment are
always insufficient, under development, and behind the current need as we
experienced before.
Back to the example I brought up, the bug was in jitted code and we have no
any debug info even in debug mode due to our own compiler (Here is a
specific example of insufficient tool). The source code (python-like our own
internal language) looks all right. I have to look back the jitted code
generated by our own compiler. Even though, some other tool such as IBM's
graphviz is very useful to eventually find the bug in compiler.
Reading assembly code is not a big deal. My point is that the code is jitted
without saving caller frame register due to register pressure, you cannot
immediately trace back to locate bug in source code and have to do some
extra work. Even though your code may be correct but the jitter could be
wrong.
【在 r********3 的大作中提到】
: 做多线程的调试，要深入到汇编级别看具体那个CPU执行了啥指令，那说明你的整个多
: 线程运行的环境和测试多没有搭建好。有经验的人，在写多线程的时候，就会考虑到如
: 何去测试和调试这部分的code。有了这个意念之后，99.999%的问题都可以在你的测试
: 框架下完成，不用搞到汇编级别去看CPU的操作。另外，你多线程的开发，不应该依靠
: 断点去调试。
: 关于系统内核的调试，早几十年别人做单片机和嵌入式设备的时候就很成熟了。一般芯
: 片都有专门几个引脚来介入调试设备的。专门的调试设备早就有了。
|
