调试ctx_server遇到的一些问题

1.optimized out

如上图所示，在调试过程中用p查看变量时出现optimized out标志。解决方法如下：

将GCC优化选项调整为O1或是O0
GCC在O2、O3优化选项下会将代码优化的比较多，调试器有可能会找不到变量的信息。通常可以将优化级别降低到O0，完全关闭优化，可以保留所有的变量和代码信息。使用O1优化有可能也可以看得到变量的值。

当然，这种直接降低优化级别的方法还是比较暴力的。如果你的程序比较大，运行到你需要调试的地方需要很久的情况下，通常都是行不通的，毕竟所有优化选项都关掉了，程序跑的会非常慢…

2.SIGPIPE信号

socket错误:Program received signal SIGPIPE, Broken pipe

SIGPIPE信号产生的规则：当一个进程向某个已收到RST的套接字执行写操作时，内核向该进程发送SIGPIPE信号。
SIGPIPE信号产生的场景举例
    ① 初始时，C、S连接建立，若某一时刻，C端进程宕机或者被KILL而终止（终止的C端进程将会关闭打开的文件描述符，即向S端发送FIN段），S端收到FIN后，响应ACK
    ② 假设此时，S端仍然向C端发送数据：当第一次写数据后，S端将会收到RST分节； 当收到RST分节后，第二次写数据后，S端将收到SIGPIPE信号（S端进程被终止）
在ctx_server中，如果服务进程繁忙，没有及时处理客户端断开连接的事件，就有可能出现在连接断开之后继续发送数据的情况。例如在onConnection或者onMessage函数中执行的过程比较复杂，在客户端断开连接之后继续往客户端发送了两次数据，服务器进程就会被终止。

解决办法：在程序开始的时候直接忽略sigpipe信号
///待补充具体代码

3.coredump

在上一个WebServer未关闭的情况下，开启下一个WebServer并监听同一个port，会导致错误，

4.epoll_wait 返回EINTR的问题

我们在利用 gdb 调试带有 epoll_wait ，select ，sem_wat 的多线程代码的时候可能会出现非正常返回 -1 的情况，错误原因是：Interrupted system call。这是由于

gdb调试的时候会在断点处插入一条中断指令,当程序执行到该断点处的时候会发送一个SIGTRAP信号,程序转去执行中断相应,进而gdb让程序停下来进行调试. 对于sem_wait\wait\read等会阻塞的函数在调试时,如果阻塞,都可能会收到调试器发送的信号,而返回非0值.
为了解决这个问题需要在代码中忽略由于接收调试信号而产生的"错误"返回:

例如：

if(  -1 == epoll_wait() )

{

    if(errno!=EINTR)

    {
          return -1;

    }
}