关于错误信息和bug报告

有时候如果你什么错误信息都不输出,那碰到bug的人会去找相关原因;但是如果你输出了一些错误信息,人们可能会误以为那就是bug的原因。 具体来说,例如这个bug rep: https://bugzilla.mozilla.org/show_bug.cgi?id=833117 简单来说就是很多人碰见了firefox/thunderbird crash。并且他们看见了那么一个错误信息: GLib-CRITICAL **: void g_slice_set_config(GSliceConfig, gint64): assertion `sys_page_size == 0′ failed 然后他们就认为crash是因为这个错误信息引起的。 但其实那个信息只是一个warning,具体来说就是初始化某个组件的时候检查是不是已经初始化过了,如果初始化过了就给个warning并且返回。 所以这些人crash的原因可能各不相同。但是因为看见了一个公共的warning,好多人就跑来”confirm”这个bug了。 如果你啥都不说,或者说这是个warning而不是CRITICAL错误,那多半人们会意识到有别的问题,然后贴stack trace之类,而不是都觉得“我也有这个问题”……

DTrace

这两天搞了一把DTrace,貌似还挺有意思的。 DTrace是个动态跟踪工具,可以在动态环境下向内核/程序中插入探头(probe),收集处理以及显示一些信息。 其实本来搞DTrace是为了一个FreeBSD的bug。搞chromecast的时候发现,IP multicast的目标mac不对。不过后来分析代码大致定位到了出问题的文件,然后在最新代码里发现这个bug已经修了(PR 185395),于是纯粹就是学习DTrace了。 一开始在我的机子上DTrace还跑不起来,后来发现是因为我跑的UEFI分支里的内核路径有些特别,于是DTrace找不到符号。打了个补丁(dt_kernel_path.patch)之后,dtrace终于能用了。 DTrace脚本的主体是一堆事件处理函数。跑DTrace脚本的时候,系统碰到某个符合的事件,就调用对应的函数。这些函数用D语言(不是那个D语言,是DTrace自己的一种语言)写成,语法和C差不多。基本的赋值/比较都能干,不过没有循环,也没有if/then/else。能控制流程的,基本上就是每个事件自带的条件,和三元操作符,也就是?:。 虽然前面那个bug是修了,我还是搞了个简单脚本来试DTrace。我希望观察arpresolve函数的参数和返回结果,也就是那个返回IP对应mac地址的函数。 arpresolve的原型是 int arpresolve(struct ifnet *ifp, struct rtentry *rt0, struct mbuf *m, const struct sockaddr *dst, u_char *desten, struct llentry **lle)int arpresolve(struct ifnet *ifp, struct rtentry *rt0, struct mbuf *m, const struct sockaddr *dst, u_char *desten, struct llentry **lle) 我希望查看dst里的ip地址,和desten里返回的mac地址。 DTrace脚本如下: fbt::arpresolve:entry /execname == "ping" && arg4 != …

Continue reading ‘DTrace’ »

导热硅脂

家里的台式机CPU温度过高已经很长一段时间了。一个i5-2500K的CPU,全功率运转的时候温度轻松上百,在BIOS里面看着温度监控都能到87,平时闲着也有七十几,这俨然不正常。 前两天拆开来,发现风扇里面好多灰…… 于是清理了一把。本来想着这回应该没问题了,结果开机之后状况依旧,丝毫没有好转…… 拆开来的时候发现风扇底下的导热膏已经全干了,剩下一层灰状物质分布在散热片表面和CPU表面。之前听说过导热硅脂干了会影响散热,因为硅脂干了之后,CPU和散热片之间会有空气间隙,导热很差,于是CPU的热量无法传达到散热片上。这种情况需要换新的导热硅脂。虽然没搞过,还是可以一试。于是去Amazon上随便搞了个5刀的导热硅脂,搞败了也没啥损失。   今天硅脂送到了,拆开来之后看上去是个针筒,不过比较细,头上有个盖子。 拆下CPU上的风扇,把上面的旧硅脂车掉,再把CPU拆下来也这么搞一遍。全搞干净之后,我开始研究硅脂怎么涂…… 网上说可以用玻璃棒啦针头啦之类的涂。拧开盖子之后,看上去就是个针筒头的样子。把针筒顶在散热片上轻轻按下去,出来了大约1mm粗细的牙膏样的东西。 反正我也没有别的工具,干脆直接用这个针筒的头来涂。重复着挤出来一些再抹到边上去的操作,直到看上去基本上都布满了…… 看网上的说法应该均匀涂,还要啥薄的像纸但是没有空隙…… 想想反正装上去之后就会压平的,谁管那么多……   涂完之后把风扇装回去,因为装得不太顺利还抬起来了几次。装完之后,怀着忐忑不安的心情开机…… 貌似效果还不错,BIOS里看看也就四十几,进了系统闲着也就四五十的样子。全功率跑起来,温度升…… 升…… 也就升到刚过七十。 现在跑了几个小时了,还是71~73的样子,系统温度35。看来基本上算是成功了。 之后再观察个几天,看看会不会有所反复。终于可以全功率跑程序了……

在bsd上跑ndk-build

bsd一直是个官方不咋支持的Android开发平台…… 不过靠着linux兼容层,还是可以混混的…… 首先是ndk-build会报不支持的os(FreeBSD)和arch(amd64),而且ndk-build并不会使用环境变量里定义的值。所以有两个办法: 1. 直接调用gmake env HOST_OS=linux HOST_ARCH=x86 gmake -f $NDK_DIR/build/core/build-local.mk 这样啥都不用改。 2. 修改ndk-build 把HOST_OS设置成linux,HOST_ARCH设置成x86,并且export出来。 再把GNUMAKE设置成gmake,否则会调自带的linux版gmake导致一些麻烦的事情…… 然后直接跑就行了。 跑了之后会碰到一个问题:ld会segmentation fault。看系统log可能是因为fallocate和fstatfs64系统调用没有实现的关系。 解决办法是,到ndk目录里的toolchains/*/prebuilt/linux-x86/…/bin/,如果有ld.gold,那把老的ld干掉,改成到ld.bfd的符号链接。老的ld就是ld.gold…… 其实就是gold那个新的ld调了一些新的bsd还没实现的linux的system call…… 用老的bfd里的ld就没事了……

居然又碰上一个Android的Bug

开发某物过程中已经碰见俩Android的bug了,Android有那么多bug么…… 第一个是在TextView里面加有格式的文本,可能会导致IndexOutOfBoundException…… 在Android公开issue列表里的一个对应的issue是#35466,影响Android 4.1,大约在4.1.x修复了。 第二个是如果有硬件加速的话,那么EditText里面的文字显示会有问题,输入一些文字之后,在前面插入文字,新的文字会和老的重叠起来…… 或者说,老的文字不会自动后退…… 在issue列表里有#38770是关于这个bug的。影响Android 4.1-4.1.2,在Android 4.2修复了。 看来4.1 bug很多嘛…… 难道和Project Butter有关系……