某年某月的某一天,测试人员发现我们的程序运行起来后发生了一次Crash, 但是无论如何也无法重现,也没有明显步骤,就是开始运行就Crash了,而且由于是C#的代码,Dump里面也没有多少有意义的信息,于是不了了之。
正式发布之后,不停的有客户出现类似的问题。Dump不管用,只能从系统日志中收集到一些错误信息,比如发生Crash的模块和Offset等等,通过编译时候生成的Map文件终于定位到了问题是发生在一个Intel提供的第三方库里面(具体的方法另写文章再讲)。而问题的原因其实很简单,这个第三方库是由C++写成的,但是在使用指针的时候根本就没有做判空检查,所有的指针都没有做判空检查。这个库是用来扫描UPNP设备的,我们的程序在启动的时候就开始扫描UPNP设备,正常情况下不会有问题,但是由于UPNP设备是各种各样的,有可能会取不到正确的信息,在取不到正确的信息的时候,很多指针都是NULL,如果在使用前不做检查,自然就容易Crash了!
而正是因为我们迷信这是Intel提供的第三方库,而且这个库本身非常复杂,将这个类库引入我们Solution的工程也就没有深入研究,从而导致了这个严重的问题。
可见,防御性编程是多么的重要啊!
正式发布之后,不停的有客户出现类似的问题。Dump不管用,只能从系统日志中收集到一些错误信息,比如发生Crash的模块和Offset等等,通过编译时候生成的Map文件终于定位到了问题是发生在一个Intel提供的第三方库里面(具体的方法另写文章再讲)。而问题的原因其实很简单,这个第三方库是由C++写成的,但是在使用指针的时候根本就没有做判空检查,所有的指针都没有做判空检查。这个库是用来扫描UPNP设备的,我们的程序在启动的时候就开始扫描UPNP设备,正常情况下不会有问题,但是由于UPNP设备是各种各样的,有可能会取不到正确的信息,在取不到正确的信息的时候,很多指针都是NULL,如果在使用前不做检查,自然就容易Crash了!
而正是因为我们迷信这是Intel提供的第三方库,而且这个库本身非常复杂,将这个类库引入我们Solution的工程也就没有深入研究,从而导致了这个严重的问题。
可见,防御性编程是多么的重要啊!