posted by wap, platform: SonyEricsson (Xperia Play)

function翻译成方程了?为什么那么多方程？

posted by wap, platform: SonyEricsson (Xperia Play)

可算软件安全领域的经典案例了，精彩程度和那个x光透视仪杀人的案例差不多。看完全文感觉丰田的嵌软水平相当于大学毕业2年的毕业生

posted by wap, platform: Windows

估计佳美的代码沿用了很多年了，构架大改是不可能了，只要架构还是那么烂，基本上新佳美的稳定性还是一个鸟样。不过架构重写的话，开发成本应该会很高。

posted by wap, platform: Windows

据说是ECM的图片，大家欣赏一下

调查发现这套系统没有采用具备侦错修正功能（EDAC）的主内存（丰田之前宣称采用了这类硬件），这点丰田必须死了

本帖最后由 性博士 于 2013-11-2 22:10 通过手机版编辑

posted by wap, platform: Android

引用:

原帖由 @deadpuppet  于 2013-11-2 22:43 发表
我就是觉得Barr的调查思路很奇葩啊：
1、设计业余。一个函数超过1300行代码怎么了，超过7k行的函数我都见过。这就一定出现Bug么？全局变量多也一定会产生Bug么？当然我也很讨厌这种设计，但不能说明他有Bug，如果想证明的话，需要找出实质证据。
2、代码不符合编码规范。我又惊了，这在业内太正常了吧？估计是使用了PCLINT或是什么工具检查了一下编码规范就蹦上来，说这会产生Bug。
递归就一定产生Bug么（递归我还真就用过一回，在后续的派生项目里还真就出现内存分配不足死机的bug）
有的程序员会这么写
malloc();
while(1){
//bulabula
break;
}
free();
如果想证明不符合编码规范，请找出证据
3、变量保护其实也是编码规范的一种，同上。

然后Barr为了证明这些代码的确有问题，使用了单元测试的方法
人为地改变了内存中的一个地址的值，于是出Bug了
那么，这个Case在实际情况中真的会发生么？

正常的路子应该是先根据用户提供的现象以及操作步骤去尝试再现这处Bug，（或者还有Log等），再结合代码，逆向分析出这个Bug的原因。
或者我就单纯分析代码，分析出至少一条能够导致出现这个Bug现象的Case，然后去再现它。
还人为地翻转一个特定字节，你怎么不去把用于通信的线缆都剪折了然后再测测？也能出Bug，出不了Bug你再把刹车拆了
难道陪审团里没有懂编程的？

最后照例乱喷一通：MBD现在经常新员工直接上（包括日本人与德国人），各种奇葩代码层出不穷，我艹。
至于前面有人提到的德国人的严谨，我更是懒得喷，能有多严谨，stop的时候不释放内存，原来是架构里根本就不支持（贼tm长见识）
PS：另外DTC模块的代码我也写过一小部分，头回知道DTC全称，寒自己一个

一个函数1300多行不能说明一定有bug，但哪个奇葩公司会在自己的编程规范里规定一个函数最大可以写1400行？要么是电装根本没编程规范，要么是码农没遵循规范。两种都是不靠谱行为。

misra c检查不过同理。就是tg数码区看不起的中兴，cdma基站的代码都是要求跑pclint全过，而且是check in时强制检查。给我们公司培训的前zte工程师亲口说的。

barr检查了代码发现位翻转会导致任务挂掉，注入一个位翻转错误结果验证了想法，这个不该喷吧。第一证明了出现问题的可能性，位翻转可能会导致任务挂掉。再说位翻转本来就是容易出现的现象，如果很少见ecc内存卖谁去？况且ecu工作环境本来就脏乱差。第二说明电装的测试范例覆盖不全，根本没考虑到位翻转的情况。假设电装的测试工程师做黑盒，模拟一个位翻转结果挂了，这就是一个必须修复的严重等级的bug。事实是这个bug根本没被测出来过。

一些罕见的错误确实会导致严重后果，还是上面说的那位培训师，他说光通信出现误码的概率很低，10的负好多次方。由于通信量很大，短期内就发生一些奇怪的问题。后来他们注入错误，生成各种错帧，把解帧引擎的错误排查干净了，就很少出问题了。

posted by wap, platform: Windows

引用:

原帖由 @zo  于 2013-11-5 19:46 发表
出乎意料
很多转帖，只有无忌的转帖最火。
而汽车论坛的基本上没人讨论。

http://forum.xitek.com/thread1229404112.html

汽车论坛那些托黑才不感兴趣，他们感兴趣的是皮厚不厚，有没有防撞梁，关门声音好不好听，底盘厚不厚重，0到100要跑几秒，有没有德味。

posted by wap, platform: SonyEricsson (Xperia Play)

引用:

原帖由 @Brienza  于 2013-11-6 03:58 发表
堆栈溢出直接写到OS的内存区域这个不可信，一个是进程地址一个是OS地址，直接写是会报错的
拿X86来说，你直接往内存地址0写数据，就会报segmentation fault，因为地址0不属于当前进程的内存范围
要不然随便什么进程都可以往内存随便什么地方写东西，整个系统立马就崩溃了

当然，什么一万一千个全局变量，1300行长的函数这些地没法洗

我搜了一下电装的主芯片，好像多数用的nec的v850，当然后来改用飞思卡尔的powerpc了。05版佳美比较老，估计还是850的芯片，这样的话内部根本没有mmu，所以os和进程本来就是在同一地址空间。

堆栈下面紧跟着就是任务管理区，这个隐患很大。stack爆了os跟着遭殃。

还有种情况也容易想到，指针变量的某个bit变位，导致指针操作写到os变量区…当然这个变位发生的可能性太低