DbgHelp教程1——初始化

以下是初始化DbgHelp最简单的代码: SymSetOptions函数是设置DbgHelper的功能选项,具体用法见https://msdn.microsoft.com/en-us/library/windows/desktop/ms681366(v=vs.85).aspx。 SymSetOptions参数为0的时候,表示所有的选项都关闭,一下是常见的选项解释: SYMOPT_ALLOW_ZERO_ADDRESS。允许符号没有地址。默认的DbgHelp会过滤掉没有地址的符号。 SYMOPT_CASE_INSENSITIVE。所有的搜索符号不区分大小写。 SYMOPT_DEBUG。通过OutputDebugString或者SymRegisterCallbackProc64... Read More | Share it now!

Blink/Webkit浏览器内核崩溃分析过程总结

前两天技术团队旺旺群里有同事提出一个问题:在debug模式下,Chromium浏览器打开http://product.suning.com/125073744.html页面renderer进程就立即崩溃。团队对于Blink/Webkit内核问题的分析经验不多,故把分析过程写出一个总结,希望对大家以后分析此类问题有帮助。 多进程调试 Chromium浏览器是多进程的架构。而Blink内核在renderer进程,debug模式下,VS调试不能抓到renderer进程的异常,也就无法定位问题。所以解决问题的第一步是把VS调试器附加到问题相应的renderer进程。 Chromium已有一篇文档讲述如何调试Chromium。对于浏览器子进程的调试,有一个–wait-for-debugger-children的命令行参数。给浏览器传递这个命令行参数之后,生成的子进程都会在一开始等待调试器60秒附加上去。另外这个命令行还可以指定是plugin进程还是renderer进程。因为这次调试的对象是renderer进程,故我们在VS调试器设置–wait-for-debugger-children=renderer传递给被调试的浏览器。 重现问题 用VS打开Chromium的源代码工程,并在debug模式下运行。启动浏览器之后,新建tab页,在地址栏里输入会导致renderer进程崩溃的网址http://product.suning.com/125073744.html。这时候就是生成对应的renderer进程。这个renderer进程在60秒等待我们把调试器附加上去。 我们找到新建renderer进程的PID,然后用VS的debug->Attach... Read More | Share it now!

visual studio的Function Evaluation调试功能

今天公司技术群里老大提及GDB调试器有个牛逼的功能,在断点的情况下执行程序里的函数。如下代码: 在GDB中直接输入a.print或者pa->print()就执行a对象的print方法,有时候这样对于调试非常方便。然后有其他同事说vs也有类似功能,叫做Immediate... Read More | Share it now!

visual stdio调试中的数据类型可视化Debug Visualizers

前言 c++可以灵活自定义非常复杂的数据结构,比如标准库中的vector,map,还有很多是用户自定义的数据。通常调试器只能解释显示一些基本的数据变量,比如int,float,能够漂亮的显示标准库的那些类就算非常不错了,比如string。对于一些用户自定义的类型,往往调试器显示出来的变量值没有什么用,有时候就想能够自己自定义的方式友好的显示调试变量值。 之前vs是通过autoexp.dat的方式支持用户自定义显示变量值,如这篇博客所介绍的:Customize... Read More | Share it now!

chromium中的性能优化工具syzyProf

函数性能分析工具SyzyProf 我先开始介绍SyzyProf。这个工具可以捕获每个线程调用每个函数执行的时间,然后把结果生成一个KCacheGrind能够识别的数据格式文件,然后通过KCacheGrind的展示结果。你就可以知道函数哪个函数执行了次数最多,消耗的时间最多,哪个线程在读写文件,哪个线程在创建窗口界面,而且KCacheGrind以图形的方式显示出函数调用链等信息,非常直观。如图这是我生成CEF自带demo程序的函数调用信息。 其实能够函数性能分析工具已经够多了,比如xperf,AQTime,还有visual... Read More | Share it now!

windbg调试内存破坏之栈溢出

当线程覆盖了为其他用途所保留的桟空间时,就是发生了栈溢出Overflow.桟溢出包括覆盖桟帧的返回地址,覆盖整个桟帧,或者消耗尽桟空间等情况。桟溢出将带来各种后果,包括程序崩溃,未预期的行为,甚至严重的安全漏洞。 运行这个程序,如果输入一些短的字符串,那么程序似乎运行起来没有问题。如果输入一个很长的字符串就会导致崩溃。 我们看下崩溃时的状态很奇怪: 乍一看,桟破坏的很严重。我们看下当前的指令指针eip   这块内存的内容是一系列?,代表这不可访问的内存。我们可以假设程序中用于控制执行流程的指令指针可能被破坏了。 我们再看看桟上的内容:   桟上的内容是aaaaaaaaaaaaaaaaa是我们输入的命令行参数。看上去桟上的内容还是正确的。 桟的ret指令会把00610061当作指令的返回地址,程序将从这个返回地址继续执行。但是我们知道00610061是无效的地址。所以崩溃的原因是执行ret指令将导致eip被设置成一个错误的返回地址,如果程序从这个错误的返回地址开始执行,将发生访问违例。 看代码,用字符串复制函数之前的桟是正确的,因此在执行字符串复制期间肯定发生了某个事件导致桟被破坏。从代码中看出HelperFunction如果复制超过MAX_CONN_LEN的字符串将发生桟溢出。 windows驱动开发包里面包含一个PREfast的工具,可以在编译时检测一些代码缺陷。从vs2008开始,已经集成了这个功能。 ... Read More | Share it now!