Debug

每个C/C++程序员都知道，对于#include directive，一般，以双引号引用的头文件是程序号自定义的头文件。而用尖括号引用的头文件是系统的头文件或其它库文件。 更详细的，编译器先在当前目录找用双引号"“引用的头文件，如果找不到再到系统目录找这个头文件。而对于尖括号引用的头文件，编译器就只在系统文件中搜索了。 那么，到底是在哪些目录中搜索头文件呢？ 可以用cpp查看，如下： root@vicarious:/home/kamus/projs/horoscope/boost# cpp -v Using built-in specs. COLLECT_GCC=cpp Target: x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-5) COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -E -quiet -v -imultiarch x86_64-linux-gnu - -mtune=generic -march=x86-64 ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-linux-gnu/4.7/include /usr/local/include /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed /usr/include/x86_64-linux-gnu /usr/include End of search list. 一般编写makefile时给gcc指定 -I选项，-I的参数代表的目录是搜索系统头文件时使用的目录。可以试试# cpp -I/tmp -v /tmp目录会被添加为搜索系统头文件时的第一个目录。 如果想要添加搜索双引号"“引用的头文件使用的目录呢，用 -iquote 选项指定更多的目录。 ...

一个稍微有经验的Linux程序员都知道使用LD_LIBRARY_PATH 来临时设置加载器搜索动态链接库so的路径顺序。但另一个不为人知的环境变量是LD_DEBUG。这个变量可以提供非常详细的加载动态链接库的信息。 可以把LD_DEBUG设成以下值： export LD_DEBUG=files # 显示库的依赖性和加载的顺序 export LD_DEBUG=bindings # 符号绑定 export LD_DEBUG=libs # 显示加载器查找库时使用的路径的顺序 export LD_DEBUG=versions # 版本依赖性 export LD_DEBUG=help # LD_DEBUG的帮助信息 试一下把LD_DEBUG设成以上值之一，再随便运行一个程序试试。 一个试验： root@vicarious:/home/kamus/projs/horoscope/bins# export LD_DEBUG=libs root@vicarious:/home/kamus/projs/horoscope/bins# vim my.conf 24360: find library=libm.so.6 [0]; searching 24360: search cache=/etc/ld.so.cache 24360: trying file=/lib/x86_64-linux-gnu/libm.so.6 24360: 24360: find library=libtinfo.so.5 [0]; searching 24360: search cache=/etc/ld.so.cache 24360: trying file=/lib/x86_64-linux-gnu/libtinfo.so.5 24360: 24360: find library=libselinux.so.1 [0]; searching 24360: search cache=/etc/ld.so.cache 24360: trying file=/lib/x86_64-linux-gnu/libselinux.so.1 24360: 24360: find library=libacl.so.1 [0]; searching 24360: search cache=/etc/ld.so.cache 24360: trying file=/lib/x86_64-linux-gnu/libacl.so.1 24360: 24360: find library=libgpm.so.2 [0]; searching 24360: search cache=/etc/ld.so.cache 24360: trying file=/usr/lib/x86_64-linux-gnu/libgpm.so.2 24360: 24360: find library=libc.so.6 [0]; searching 24360: search cache=/etc/ld.so.cache 24360: trying file=/lib/x86_64-linux-gnu/libc.so.6 24360: 24360: find library=libdl.so.2 [0]; searching 24360: search cache=/etc/ld.so.cache 24360: trying file=/lib/x86_64-linux-gnu/libdl.so.2 24360: 24360: find library=libattr.so.1 [0]; searching 24360: search cache=/etc/ld.so.cache 24360: trying file=/lib/x86_64-linux-gnu/libattr.so.1 copyright ykyi.net

今天程序崩溃了，但是生成的core文件大小是0. 用ulimit -c 查看生成core文件的大小限制是无限unlimited. 也不是磁盘大小和写入权限的问题。 但究竟是什么问题呢？ 捣了半天终于搞明白，原来是文件系统造成的。 我是在vmware的虚拟机的debian linux上运行程序，文件系统用的是从host机windows 7挂载到/mnt/hgfs的windows的NTFS文件系统。 后来我把程序转移动linux自己的文件系统，崩溃的时候就生成正常的core dump文件了。 copyright ykyi.net

追踪点（Tracepoint）被当成断点(breakpoint)的一种，但有两个不同点需要注意： 1. 当一个追踪点在一个调试会话中被创建时，它并不种入到二进制代码中，直到用户显式地开始追踪实验。这意味着，创建/修改/删除追踪点并不影响程序，直到追踪真正开始。 2. 简单的创建一个追踪点并不是非常有价值，因为它默认不会收集任何信息。重要的是，把操作(Actions)添加到Tracepoint，这样tracepoint被触发的时候，前面自定义的Action就大有用处了。 来自CDT官网的原文： Create Tracepoints ...

这几天换成用eclipse在windows机器上编写代码，远程运行在linux上，并且在windows机器上远程调试。 新建一个C++类的时候，eclipse/CDT自动生成注释，注释的时间用了中文，并且用的注释风格也不是我想要的。 但我想全部用英文，这个如何解决了。在stackoverflow上找到了答案，并试验成功。 windows -> preferences -> c/c++ -> code style -> code template 在右边的注释模板中编辑File Comment，改成你想要的模式。比如我的： /***************** * ${file_name} * Author: ${user} * Created on: ${date} ******************/ 再在eclipse的安装目录上找到eclipse.ini文件，加入：-Duser.language=en_US 重启eclipse。现在${date}变量生产的日期就是全英文了。 copyright ykyi.net

用gdb在远程linux机器上调试程序实在太不方便了。于是想到用eclipse的GUI调试。下面介绍如何从windows远程调试linux程序。 ...

在这里记下我的程序BUG buff溢出后，把栈破坏了，这个线程也没崩溃，一直死循环在一小段不可知的代码里。 #调用getaddrinfo很多次以后，getaddrinfo报错：No address associated with NAME。非常地奇怪呀后来把同样的程序部署到比较旧的linux上，报错: Too many open files。才明白，原来fd被用光了。回头再检查相关代码，果然如此~补上close(fd)后，getaddrinfo的问题也解决了。启发是：1. 有些报错信息其实离真正的错误原因很远。2. 一个系统调用一开始正常，跑了很多次后失败，应该怀疑是不是有资源泄露。 #把uint_t类型赋值给std::string时，会崩溃在std::string里面。 #当一个预期统一的规则出现特例的时候容易出现BUG. 关联订单，关联片区，入货地址都指受YYYY-MM-DD HH:MM:SS的时间戳，但同机分析接受的时间戳却是YYYYMMDD某一天的时间戳。有一个组合需求是同时导出上述4个小需求时，由于传入的时间戳参数不一致导致了BUG. vector::push_back可能会重新分配vector的内存，导致指向之前元素的引用和指针失效.一个std::function持有一个std::ref指向vector中的一个元素，当这个funcction被调用的时候，vector中的这个元素已经失效了。 # 用boost::optional记录一个信息。这个信息没及时在clear函数里做清理。于是，观察到的情况时，这个信息总是被打印。但一开始，我们却怀疑是另外的函数不稳定而重新生成了该信息。 在写一个匹配函数时，待匹配操作数是一个字符串，我没有考虑字符串是空串的情况。 在比较旧的gcc 4.1.2上把shared_ptr赋给 weak_ptr时，崩溃。溃在atomic_exchange_and_add。一开始怀疑是旧版gcc对boost的智能指针支持的不够好，后来发现是因为weak_ptr此时已经失效了。原因是用handler的参数持用shared_ptr的引用做生命期管理时，传错了参数，使得这个对象已经被销毁了。 现象：一个依赖某布尔变量的逻辑大多数时候正常，少部分时间异常。期望这个布尔变量是false，有时候陌名其妙变成了true。 原因是此布尔变量未被初始化，大多数时候它的值是false，但有时却不是。 #. 现象rmap_item泄露. Fix it: 单链表插入新结点时指针操作出错。应该是new->rmap_list = _item，被我写成 new->rmap_list = (_item)->rmap_list. #. 我意图注释掉某行代码，却鬼使神差注释错了一行代码。 #. 变量名 pkt 和ptr 很像，在用memcpy函数时用错了变量导致bug. 一块内存被莫名其妙的修改了，很有可能是因为像刚才这样写这块函数的参数填错了。 #. _sessions.erase(ite++);删除了_sessions维护的一个对象.对象的析构被调用，会有一连串对象的析构因此而被调用。这些对象中的指针很可能就失效了。但是，在代码的其它地方还能拿到这个指针。野指针啊！！！今天这个例子中是session维护的ip_pkt对象都被析构了，ip_pkt中的指针也都失效了。于是，一使用野指针，崩溃了。 #. 删除数据时，总是要注意其它代码中指向这些被删除数据的引用或指针。 #. 解引用container.end()返回的迭代器会崩溃。 #. 这是个腾讯视频广告投放组的bug. 一个线程负责开，关FD。另一个线程读写FD。两个线程的竞争条件造成了BUG. #. 写代码时偷懒复制代码，然后忘记做相应更改，视觉上很难在第一时间察觉，却在后期花费了几倍时间调试程序。 #. 写判断语句时，判断表达示如 container.empty()之前是否要取反，经常搞错。 #. htonl 写成 htons #. std::distance 计算两个迭代器之间距离时死循环，是因为迭代器没有初始化。而我之前想，作初始化工作的函数已经调用了，实际上并没有被调用。 #. 没注意函数的返回值. 有时函数返回0时表示成功，即true的含义。所以看到一些和预期刚好相反的现象时，应该考虑是不是出现了这样的错误。 ...