不作文，只记要点。
1.Ice::Application的程序框架默认对SIGHUP, SIGINT, SIGTERM进行处理。目的就是捕捉Ctrl+C发出信号有序地结束程序。这个功能扰乱了我们使用gdb进行调试。
1.1 Ice::Application通过CtrlCHandler类，使用pthread_sigmask对所有其它线程都阻塞上面三个信号。
1.2 可以参看线程sigwaitThread，以及Ice::Application类几个虚函数如何扩展Ctrl+C信号的处理。
2. gdb调试时，我们往往会通过Ctrl+C来手动中断正在运行的调试程序，但不幸的是这会发出一个SIGINT信号，即使你希望通过命令"handler ignore SIGINT"来阻止信号到达调试程序，但是你只能失望，结果是你希望Ctrl+C来中断调试程序，却结束了调试程序。
3. ddd调试，ddd是一个gdb前端，作为一个前端，你的前端窗口功能也可能会发中断信号到gdb，从而到达调试程序。例如你要观察调试程序的标准输出，你从view|excution window打开了一个窗口，这个窗口专门用来显示调试程序的输出。但是当你调整这个窗口的大小时，意外的事情发生，后端gdb居然接收到了一个SIGINT信号，也就是说当你调整窗口时，前端会中断一个后端的调试，窗口就绪后继续调试进行。这样一来，中断信号被调试的程序捕捉并结束了。
4. kdevelop调试，同样是一个gdb前端，当在调试程序在运行中，你希望通过代码界面添加某行的中断断点，这时候意外又来了。因为你使用gdb命令，都必须在gdb对调试程序中断的状态下进行，所以你在界面操作添加一个中断断点，其实就等同于，你Ctrl+C去中断程序，然后在gdb命令，添加断点，再继续调试。这样一来界面因为你的操作向后台gdb发送了一个Ctrl+C信号，又至使Ice::Application捕捉信号结束运行。
5. ddd提供四个调试窗口，变量监视窗口，源代码窗口，反汇编窗口，还有就是gdb命令控制窗口。在有源代码的情况下进行调试，是方便很多的，因为它自己在每一处暂停都会自动反汇编并关联到代码。虽然我们可以组合（disass /m, f等）命令，但调试体现还是ddd好。一但找不到源代码时，ddd的行为就不可期望（unexpecred）。要么一直忙，要么失去控制，反正就是无法调试下去。拿远程调试android为例，ndk提供的cxx-stl的库，它的源代码路径在 “/usr/local/google/buildbot/src/android/ndk-r15-release/out/build/tmp/build-130720/build-gnustl/static-armeabij4.9/build/include”。一但单步跳进了stl库的函数，由于找不到源代码，ddd的行为就很古怪，没办法继续调试下去。如果使用gdb还好，报错就是了，如下图，却不影响调试。
准备和建立远程调试，操作步骤比较烦，如果正调试到入正题的时候，调试器前端闹别扭，那就是相当烦的事了。而且远程调试通过 tty（或者叫COM），响应速度那个就是一个等字。