一个二面都没拿到，我怎么这么笨呀# Accounting - 会计审计
B*D
1 楼
如果说The Wire是表现美国城市的崩溃的
这个Empire是说的就是30年代禁酒令时期的Atlantic City的政治画卷
偶这个p民看高层政治斗争，觉得没有很多把刷子还是当p民好
这个Empire是说的就是30年代禁酒令时期的Atlantic City的政治画卷
偶这个p民看高层政治斗争，觉得没有很多把刷子还是当p民好
w*a
3 楼
最可怕的bug,是很难重复的bug
m*o
4 楼
实在是抓狂了，以前对web编程一窍不通，现在要赶鸭子上架。
现在的任务是需要通过web来进行远端数据库查询，web server是tornado（python）。
网页交互式的我已经弄出来了。现在的问题是要做成命令行形式的。比如说用户输入
curl -d "query=select * from dummy" www.foo.com/
要能在终端下返回CSV格式或者JSON格式的结果
我做了个helloworld程序，如果用户输入
curl -d "user=helloworld" http://127.0.0.1:8888
终端可以返回helloworld。现在的问题是如果我让程序跳转到另外一个url，比如http://www.foo.com/user/helloworld,
终端下什么夜没有输出。我已经再第二个页面下的get和post方法下都实现了打印“
helloworld”。测试过网页，跳转一点问
题都没有。
哪位有经验的给讲讲，多谢！
现在的任务是需要通过web来进行远端数据库查询，web server是tornado（python）。
网页交互式的我已经弄出来了。现在的问题是要做成命令行形式的。比如说用户输入
curl -d "query=select * from dummy" www.foo.com/
要能在终端下返回CSV格式或者JSON格式的结果
我做了个helloworld程序，如果用户输入
curl -d "user=helloworld" http://127.0.0.1:8888
终端可以返回helloworld。现在的问题是如果我让程序跳转到另外一个url，比如http://www.foo.com/user/helloworld,
终端下什么夜没有输出。我已经再第二个页面下的get和post方法下都实现了打印“
helloworld”。测试过网页，跳转一点问
题都没有。
哪位有经验的给讲讲，多谢！
h*3
5 楼
2家4大的面试都没有进二面，都对自己没信心了，大家都是怎么准备面试的呀，我是真
的不知道问题出在哪里了。。。
的不知道问题出在哪里了。。。
R*I
6 楼
是二十年代
【在 B*D 的大作中提到】
: 如果说The Wire是表现美国城市的崩溃的
: 这个Empire是说的就是30年代禁酒令时期的Atlantic City的政治画卷
: 偶这个p民看高层政治斗争，觉得没有很多把刷子还是当p民好
【在 B*D 的大作中提到】
: 如果说The Wire是表现美国城市的崩溃的
: 这个Empire是说的就是30年代禁酒令时期的Atlantic City的政治画卷
: 偶这个p民看高层政治斗争，觉得没有很多把刷子还是当p民好
w*y
7 楼
你每天都在comic版混啊，呵呵
【在 s******s 的大作中提到】
: http://www.bilibili.us/video/av76784/
【在 s******s 的大作中提到】
: http://www.bilibili.us/video/av76784/
r*3
8 楼
这个还用你说。。。
所以我们面试程序员都说，没有接触过multithread programming的，再牛顶多只能算
中级程序员。
【在 w*********a 的大作中提到】
: 最可怕的bug,是很难重复的bug
所以我们面试程序员都说，没有接触过multithread programming的，再牛顶多只能算
中级程序员。
【在 w*********a 的大作中提到】
: 最可怕的bug,是很难重复的bug
s*k
9 楼
跳转是怎么实现的？ 用http header里面的location还是用javascript之类的？
我刚才试了一下一个跳转网页,用的是设置返回http status code 301，http header
field中的location设置成要跳转的url, 浏览器的话会根据收到的http header处理跳
转.用curl的话就显示
$ curl http://192.168.1.100/pub
301 Moved Permanently
我刚才试了一下一个跳转网页,用的是设置返回http status code 301，http header
field中的location设置成要跳转的url, 浏览器的话会根据收到的http header处理跳
转.用curl的话就显示
$ curl http://192.168.1.100/pub
Moved Permanently
The document has moved http://192.168.1.100/pub/">here.
w*1
10 楼
别灰心，原因可能有很多，你可以到四大的career网站上面找点面试题，自己事先准备
好答案，面试时候灵活应对就好~
好答案，面试时候灵活应对就好~
B*G
11 楼
Empire还是基本走富丽堂皇的时代剧路线的，很drama。The wire实在是太写实了，这
隔中国就叫批判现实主义。
【在 B*D 的大作中提到】
: 如果说The Wire是表现美国城市的崩溃的
: 这个Empire是说的就是30年代禁酒令时期的Atlantic City的政治画卷
: 偶这个p民看高层政治斗争，觉得没有很多把刷子还是当p民好
隔中国就叫批判现实主义。
【在 B*D 的大作中提到】
: 如果说The Wire是表现美国城市的崩溃的
: 这个Empire是说的就是30年代禁酒令时期的Atlantic City的政治画卷
: 偶这个p民看高层政治斗争，觉得没有很多把刷子还是当p民好
M*n
12 楼
他是本版第一伪娘，不要欺负他
【在 w****y 的大作中提到】
: 你每天都在comic版混啊，呵呵
【在 w****y 的大作中提到】
: 你每天都在comic版混啊，呵呵
w*a
13 楼
这年头还有没接触过multithread的程序员？
连初级的都不算
【在 r********3 的大作中提到】
: 这个还用你说。。。
: 所以我们面试程序员都说，没有接触过multithread programming的，再牛顶多只能算
: 中级程序员。
连初级的都不算
【在 r********3 的大作中提到】
: 这个还用你说。。。
: 所以我们面试程序员都说，没有接触过multithread programming的，再牛顶多只能算
: 中级程序员。
s*s
14 楼
我发现好多马甲都在默默地注视我。
【在 M******n 的大作中提到】
: 他是本版第一伪娘，不要欺负他
【在 M******n 的大作中提到】
: 他是本版第一伪娘，不要欺负他
r*3
15 楼
你问问这个版上做machine learning，computer vision，有几个接触过thread和
process。
相当一部分，连thread和process的概念是什么都不清楚，他们只用matlab。
【在 w*********a 的大作中提到】
: 这年头还有没接触过multithread的程序员？
: 连初级的都不算
process。
相当一部分，连thread和process的概念是什么都不清楚，他们只用matlab。
【在 w*********a 的大作中提到】
: 这年头还有没接触过multithread的程序员？
: 连初级的都不算
a*e
16 楼
排人气包！
【在 s******s 的大作中提到】
: 我发现好多马甲都在默默地注视我。
【在 s******s 的大作中提到】
: 我发现好多马甲都在默默地注视我。
g*g
17 楼
我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
有半个小时一次的thread dump里能看到异常。
Operation team把我老拉近conf room边debug边开会，
客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
是多线程问题，但无法重现。产品环境，log level太高，无充足信息。只好在
核心代码里反复阅读猜测，写测试验证。日夜干了2周没能解决，有天做梦突然
想到某行代码可能有并发问题，侥幸解决。
服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
有半个小时一次的thread dump里能看到异常。
Operation team把我老拉近conf room边debug边开会，
客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
是多线程问题，但无法重现。产品环境，log level太高，无充足信息。只好在
核心代码里反复阅读猜测，写测试验证。日夜干了2周没能解决，有天做梦突然
想到某行代码可能有并发问题，侥幸解决。
s*s
18 楼
春光明媚的星期天还在辛勤地劳动，你们也不说给俺发几个包子。。。
【在 a****e 的大作中提到】
: 排人气包！
【在 a****e 的大作中提到】
: 排人气包！
d*n
19 楼
赞梦郎。
注意休息啊。
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
注意休息啊。
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
M*n
20 楼
吃！
【在 a****e 的大作中提到】
: 排人气包！
【在 a****e 的大作中提到】
: 排人气包！
w*g
21 楼
牛啊，谢谢分享
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
c*p
22 楼
有些问题想得时间长了确实是会在梦里有想法的。
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
【在 g*****g 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
w*a
23 楼
最可怕的一个是系统crash，每crash一次公司赔偿60多万人民币，我接手的时候已经
crash了20多次，整个单子才不到1500万。因为涉及其他厂商联调，必须在产品环境中
debug..
crash了20多次，整个单子才不到1500万。因为涉及其他厂商联调，必须在产品环境中
debug..
N*D
24 楼
machine learning, computer vision, 算法有了bug, 查起来也是非常困难的
【在 r********3 的大作中提到】
: 你问问这个版上做machine learning，computer vision，有几个接触过thread和
: process。
: 相当一部分，连thread和process的概念是什么都不清楚，他们只用matlab。
【在 r********3 的大作中提到】
: 你问问这个版上做machine learning，computer vision，有几个接触过thread和
: process。
: 相当一部分，连thread和process的概念是什么都不清楚，他们只用matlab。
p*t
25 楼
adobe flash会导致手机crash,搞得apple都不用它.現在大部分网站的主页的那个动态
图,很少有用flash的了.
【在 w**a 的大作中提到】
: 最可怕的一个是系统crash，每crash一次公司赔偿60多万人民币，我接手的时候已经
: crash了20多次，整个单子才不到1500万。因为涉及其他厂商联调，必须在产品环境中
: debug..
图,很少有用flash的了.
【在 w**a 的大作中提到】
: 最可怕的一个是系统crash，每crash一次公司赔偿60多万人民币，我接手的时候已经
: crash了20多次，整个单子才不到1500万。因为涉及其他厂商联调，必须在产品环境中
: debug..
x*n
26 楼
你这是一秆子打倒一片人,难道做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。
有些做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
27 楼
没有打倒一片，但是大多数的还是有。你这个都是做到产品级的，当然不一样了。
掉,
【在 x****n 的大作中提到】
: 你这是一秆子打倒一片人,难道做vision/AI/ML的人真这么弱吗?
: 有些做vision的系统也会作的极其变态,几十个算法都是用c++和java写的,每个有好几
: 个thread一起运算,运算数据量大,流程又复杂,稍微不注意就会把其他task的内容冲掉,
: 还要求连续不停机工作至少两周
: 我遇到的bug比如,系统运行一周后崩溃了,查log追溯最后几个小时,至少几个G的log,但
: 是log也被冲了一半,最后只能读代码,平均一个算法4千行,挑几个嫌疑最大的先看,写测
: 试模拟来加快测试,dump系统十几个GB的内存来看,发觉memory fragmented,最后对每一
: 个算法改写让其更安全,总算在产品phase到期之前测试通过.
掉,
【在 x****n 的大作中提到】
: 你这是一秆子打倒一片人,难道做vision/AI/ML的人真这么弱吗?
: 有些做vision的系统也会作的极其变态,几十个算法都是用c++和java写的,每个有好几
: 个thread一起运算,运算数据量大,流程又复杂,稍微不注意就会把其他task的内容冲掉,
: 还要求连续不停机工作至少两周
: 我遇到的bug比如,系统运行一周后崩溃了,查log追溯最后几个小时,至少几个G的log,但
: 是log也被冲了一半,最后只能读代码,平均一个算法4千行,挑几个嫌疑最大的先看,写测
: 试模拟来加快测试,dump系统十几个GB的内存来看,发觉memory fragmented,最后对每一
: 个算法改写让其更安全,总算在产品phase到期之前测试通过.
h*i
28 楼
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 的大作中提到】
: 我碰到最可怕的，是在产品环境上出了递归死循环，是因为不知名第三方的邮件
: 服务器有问题引起的，所以测试的时候没有发现。结果就是那个用户登录
: 的节点栈溢出，5分钟就JVM重启，重启就导致那个用户自动登录其他节点，
: 其他节点就重启，幸好节点多，但还是很惨烈。这种错在log里没有痕迹，幸好
: 有半个小时一次的thread dump里能看到异常。
: Operation team把我老拉近conf room边debug边开会，
: 客户每3分钟问一次状态，压力可想而知。幸好30分钟的时候找到了毛病，
: 封住了那个用户，再花了一个下午修改代码。合同是99.9%的availability，
: 如果超过8个小时解决不了那个大单可能就要丢，搞不好要裁员也有可能。
: 最难的，碰到一个大集群里，有节点不定期变慢堵塞，周期一到两周不等，知道
g*g
29 楼
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.
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
30 楼
clojure 在看,感觉比scala简洁...
A*o
31 楼
看不到输出，驱动，内核什么的代码很难de
F*k
32 楼
我来说个实战的例子：
128个线程同时跑在30多个核上，断点极难捕捉。最终确定bug可能是在jitted code中
，虽然截获断点，因为是自己产生的jitted code, caller frame指针被重设，不能回
溯到caller,只能看汇编代码。最终发现产生代码的register allocator在某个特定的
情况下对某个basic block的输入寄存器集合没有更新，导致产生的代码中有个寄存器
没有初始化。
再说个多年前和一个哥们破解一个加密软件。这个软件在并口上插加密卡。当时好像用
的一个叫IDE的巨强大的debug软件。我们连了个示波器到并口上监控哪段代码读并口。
【在 A***o 的大作中提到】
: 看不到输出，驱动，内核什么的代码很难de
128个线程同时跑在30多个核上，断点极难捕捉。最终确定bug可能是在jitted code中
，虽然截获断点，因为是自己产生的jitted code, caller frame指针被重设，不能回
溯到caller,只能看汇编代码。最终发现产生代码的register allocator在某个特定的
情况下对某个basic block的输入寄存器集合没有更新，导致产生的代码中有个寄存器
没有初始化。
再说个多年前和一个哥们破解一个加密软件。这个软件在并口上插加密卡。当时好像用
的一个叫IDE的巨强大的debug软件。我们连了个示波器到并口上监控哪段代码读并口。
【在 A***o 的大作中提到】
: 看不到输出，驱动，内核什么的代码很难de
r*3
33 楼
做多线程的调试，要深入到汇编级别看具体那个CPU执行了啥指令，那说明你的整个多
线程运行的环境和测试多没有搭建好。有经验的人，在写多线程的时候，就会考虑到如
何去测试和调试这部分的code。有了这个意念之后，99.999%的问题都可以在你的测试
框架下完成，不用搞到汇编级别去看CPU的操作。另外，你多线程的开发，不应该依靠
断点去调试。
关于系统内核的调试，早几十年别人做单片机和嵌入式设备的时候就很成熟了。一般芯
片都有专门几个引脚来介入调试设备的。专门的调试设备早就有了。
【在 F******k 的大作中提到】
: 我来说个实战的例子：
: 128个线程同时跑在30多个核上，断点极难捕捉。最终确定bug可能是在jitted code中
: ，虽然截获断点，因为是自己产生的jitted code, caller frame指针被重设，不能回
: 溯到caller,只能看汇编代码。最终发现产生代码的register allocator在某个特定的
: 情况下对某个basic block的输入寄存器集合没有更新，导致产生的代码中有个寄存器
: 没有初始化。
: 再说个多年前和一个哥们破解一个加密软件。这个软件在并口上插加密卡。当时好像用
: 的一个叫IDE的巨强大的debug软件。我们连了个示波器到并口上监控哪段代码读并口。
线程运行的环境和测试多没有搭建好。有经验的人，在写多线程的时候，就会考虑到如
何去测试和调试这部分的code。有了这个意念之后，99.999%的问题都可以在你的测试
框架下完成，不用搞到汇编级别去看CPU的操作。另外，你多线程的开发，不应该依靠
断点去调试。
关于系统内核的调试，早几十年别人做单片机和嵌入式设备的时候就很成熟了。一般芯
片都有专门几个引脚来介入调试设备的。专门的调试设备早就有了。
【在 F******k 的大作中提到】
: 我来说个实战的例子：
: 128个线程同时跑在30多个核上，断点极难捕捉。最终确定bug可能是在jitted code中
: ，虽然截获断点，因为是自己产生的jitted code, caller frame指针被重设，不能回
: 溯到caller,只能看汇编代码。最终发现产生代码的register allocator在某个特定的
: 情况下对某个basic block的输入寄存器集合没有更新，导致产生的代码中有个寄存器
: 没有初始化。
: 再说个多年前和一个哥们破解一个加密软件。这个软件在并口上插加密卡。当时好像用
: 的一个叫IDE的巨强大的debug软件。我们连了个示波器到并口上监控哪段代码读并口。
F*k
34 楼
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的操作。另外，你多线程的开发，不应该依靠
: 断点去调试。
: 关于系统内核的调试，早几十年别人做单片机和嵌入式设备的时候就很成熟了。一般芯
: 片都有专门几个引脚来介入调试设备的。专门的调试设备早就有了。
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的操作。另外，你多线程的开发，不应该依靠
: 断点去调试。
: 关于系统内核的调试，早几十年别人做单片机和嵌入式设备的时候就很成熟了。一般芯
: 片都有专门几个引脚来介入调试设备的。专门的调试设备早就有了。
相关阅读
版上大多数话题都是找工作和考试痛苦的选择，这个offer要不要？Far 考试感想EY和PwC的offer怎么选？读会计的兄弟姐们看过来AUD: "misstatement 对net income 的影响"这类题该怎么准备呢CPA学分评估机构求推荐急问， 准本约下一门CPA考试， 可是在我的ACCOUNT里就是找不到可以选SECTION的那个地方了？MBA如何选财会方向？有了绿卡更好找工作求教刚master会计毕业找工作没人回当下是不是很正常？怎么从QB里打印2012（01-08）的W２表？中国四大的审计经验在美国好不好用啊？找人合买2012 BeckerCPA 全套资料请教找到会计工作的同学门几个问题考完了，转让资料我应该辞职考CPA吗？公司里void check还用保留么？要读研, 两个admission哪个比较好?有Delaware的CPA吗，请教个CPE的问题