Debug on kamuszhou's blog

怎么知道gcc搜索头文件的路径

Thu, 13 Feb 2014 08:02:43 +0000

每个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_DEBUG调试so的加载

Wed, 12 Feb 2014 07:20:25 +0000

一个稍微有经验的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

为什么dump生成core文件大小是0

Wed, 25 Dec 2013 05:17:38 +0000

今天程序崩溃了，但是生成的core文件大小是0.

用ulimit -c 查看生成core文件的大小限制是无限unlimited.

也不是磁盘大小和写入权限的问题。

但究竟是什么问题呢？

捣了半天终于搞明白，原来是文件系统造成的。

我是在vmware的虚拟机的debian linux上运行程序，文件系统用的是从host机windows 7挂载到/mnt/hgfs的windows的NTFS文件系统。

后来我把程序转移动linux自己的文件系统，崩溃的时候就生成正常的core dump文件了。

CDT调试中的追踪点和断点有什么区别。

Wed, 11 Dec 2013 02:31:13 +0000

追踪点（Tracepoint）被当成断点(breakpoint)的一种，但有两个不同点需要注意：

1. 当一个追踪点在一个调试会话中被创建时，它并不种入到二进制代码中，直到用户显式地开始追踪实验。这意味着，创建/修改/删除追踪点并不影响程序，直到追踪真正开始。

2. 简单的创建一个追踪点并不是非常有价值，因为它默认不会收集任何信息。重要的是，把操作(Actions)添加到Tracepoint，这样tracepoint被触发的时候，前面自定义的Action就大有用处了。

来自CDT官网的原文：

Create Tracepoints

让eclipse自动生成的注释的时间显示英文，不用中文.

Mon, 09 Dec 2013 08:21:55 +0000

这几天换成用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}变量生产的日期就是全英文了。

如何从windows远程调试linux程序。

Wed, 04 Dec 2013 03:29:06 +0000

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

我的BUG大全。

Sat, 23 Mar 2013 03:32:22 +0000

在这里记下我的程序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的含义。所以看到一些和预期刚好相反的现象时，应该考虑是不是出现了这样的错误。