调试利器-----------------------DebugTrace for Windows简介

    技术2022-05-11  88

    首先申明一下,贴这个贴子的目的之一是王婆卖瓜似的推销子做的东东;梁歪一个目的呢就是希望和大家交流一下调试的技巧。:P  软件请到这里下载http://go6.163.com/spring22/html/debugtrace.htm 具体的说明在zip包内。为了能够跟踪用户需求,以及bug反映,请下载的用户发一个mail到luon@hotmail.com    实在不行的话,在这下面签个到留下你的mail地址,谢谢

     

    作为一名C/C++程序员,你最大的苦恼是什么?如何处理Debug版和release版本之间的差异?如何在realese版本里面进行调试?如何更好地调试实时程序,如何更好地调试多线城程序,如何调试GDI程序……

    我想作为一个有经验的程序员,对付这样的问题,应该都有自己的一套方法。但是能不能够把这些方法共享给大家,提供一个能够普及的东东呢?本人一直很迷惑。现在有了,答案就是DebugTrace

     

    作为一名C/C++程序员,我最大的苦恼就是数组越界访问的问题,你的呢?

    很多时候,对某个程序的调试,不是我们平时的F9[设置断点],F5[运行],F10[单步执行],F11[跳入]可以解决的。这个问题比较突出的比如GDI程序的调试,键盘程序的调试。当你按下键盘的时候,会触发键盘消息,但你移动鼠标进行操作的后,会导致出现无效区域,从而触发WM_PAINT的调用。如果被调试对象此时正好就对这些消息感兴趣的话,问题就出现了。在这种情况下,会对你的调试带来一定的影响。怎门半才好呢?常见的调试GDI的方法是双显示器或者,远程调试。键盘调试的话,用其它的输入方式来调试。这样就出现了很多针对性很强的个别方法,我们能不能够有其他通用一点的方法呢?对了!有人想到了,我们可以写LOG&TRACE文件。这肯定是一个绝好的方法,有了这样的方法,才使很多的程序员在debug的苦海里看到了一点微茫的希望。

    但是是不是有了这样的方法就一劳永逸了呢?其实问题远远不是如此。才仅仅是个开头。

    比如,想写一些信息到LOG文件里面去,可能会有如下的代码:

                          char szBuffer[20];

                                         ZeroMemory(szBuffer,sizeof(szBuffer));

                                         fprintf(pFile, szBuffer”[%d]The First Log Information”,1);

    这段代码基本上正确,初看的时候还很顺眼,但是有经验的程序员却可以一样看出其中的问题。你看出来了吗?问题在哪里?问题出在了字符数组szBuffer的长度上,发生了数组的越界访问,这样的一段程序放在程序里,无一是一颗炸弹,随时会跳出来兴风作浪。程序改进的方法就是加大数组的长度。但是在实际的情况下,究竟缓冲区需要设置成多大呢?这个很难把握的,唯一的回答就是具体情况具体分析了。如果有一个程序里面有很多的地方需要写LOG?不会是满篇都出现这样的语句吧?这样的代码,不仅运行效率不高,开发效率也不会高,还影响程序的可读性。有人说,将buffer设置成全局的,不错的主意,可是这个缓冲区究竟要设多大呢?这确实是个问题,聪明的办法是此路不通另辟坦途。

    其实可能很多人都想到了,我们完全可以用C++string来解决这个问题。当然这个问题是解决了,但是如果你想在debug版本和release版本之间稍有不通时怎么办呢?通常的办法是适用预编译指令,比如:

          #ifdef DEBUG

                          char szBuffer[20];

                                         ZeroMemory(szBuffer,sizeof(szBuffer));

                                         fprintf(pFile, szBuffer”[%d]The First Log Information”,1);

          #endif

    大量的这样的语句出现在程序中,不仅需要专门的编译器的与编译指令方面的知识,还会影响程序的可读性,而且如果一不小心与编译指令本身除了点问题的话,错误提示不能正确指示的。这反倒增加了麻烦。

    解决之道呢?强烈推荐使用DebugTraceJ

    有了写LOG文件之后,是不是就万事大吉了呢?回答当然是否定的。请考虑多线程时候的情况。在多线程的情况下,会出现什么样的问题呢?首先是我们在往disk或者memeory写文件的时候会出现问题,试想如果有很多线程再同时往同一个地方写,不会发生访问冲突吗?幸运的是在windows系列的大部分OS里面,文件I/O已经是异步访问模式了。这个不是问题,可是既然buffer是全局的,如何保证buffer的访问不发生冲突呢?这是必要用到线城间通讯与同步的技术,一个小小的写LOG操作需要这么复杂的东东来完成它,不做也罢~

     还有问题,写LOG的话,需要等待程序运行完毕了,才来验证写LOG的结果,这样的操作实时性差,在有的系统里面,需要实时地知道当前程序运行到什么地方了。写LOG有延时性的问题,怎么办呢?

    用过java的朋友都知道,在java里面可以有一个很cool的东东java虚拟机JVM,任何需要跟踪调试的信息都可以printJVM上赖进行检查,这对调试程序的程序员来讲是在事太方便了。想不想再你的C/C++程序的调试过程中也有这样的东东呢?

    想的话,不妨一试DebugTrace

    windows系统里面系统维护着一个虚拟的窗口叫做DebugWindow.使用过DBGWNDsoftice或者VC或其他开发工具自带的调试工具都用到了这些东东。习惯使用这些东东的程序员如何将自己写的信息写到里面去,在调试的时候实时检查呢?答案就在DebugTrace

    同时很多人也关心,如何将我的LOG信息写到系统的事件记录器里面去呢?这也是DebugTrace的一个功能哦。

    对于程序员来讲,调试的目的是要找出程序里面的bugBug的表现方式当然是在那个文件的那一行。如何将这些也表现到你的明明白白地告诉你呢?对于多线程的程序,如何知道那条信息,是那个线程写出来的呢?尤其是多个线程同时使用同一个线程函数的时候呢?如果堆时间要求较高的话,如何作出细微的分析呢?……

    答案就在DebugTrace

    目前的DebugTrace已经经过了好多实际项目的考验。表现一直不错。尤其在某个多线程SOCKET和另外一个COM的项目里面表现一直不错。

    有句话叫做“国之利器,不可示人”,但是我觉得有了交流才会有提高。所以但愿DebugTrace对你有所帮助。值得一试的。


    最新回复(0)