2、阻塞模式与非阻塞模式下write的返回值各代表什么意思？有没有区别？

阻塞与非阻塞write返回值没有区分，都是 <0：出错，=0：连接关闭，>0发送数据大小，特别：返回值 <0时并且(errno == EINTR || errno == EWOULDBLOCK || errno == EAGAIN)的情况下认为连接是正常的，继续发送。只是阻塞模式下write会阻塞着发送数据，非阻塞模式下如果暂时无法发送数据会返回，不会阻塞着 write，因此需要循环发送

3、阻塞模式下read返回值 < 0 && errno != EINTR && errno != EWOULDBLOCK && errno != EAGAIN时，连接异常，需要关闭，read返回值 < 0 && (errno == EINTR || errno == EWOULDBLOCK || errno == EAGAIN)时表示没有数据，需要继续接收，如果返回值大于0表示接送到数据。 

非阻塞模式下read返回值 < 0表示没有数据，= 0表示连接断开，> 0表示接收到数据。 

这2种模式下的返回值是不是这么理解，有没有跟详细的理解或跟准确的说明？ 

4、阻塞模式与非阻塞模式下是否send返回值 < 0 && (errno == EINTR || errno == EWOULDBLOCK || errno == EAGAIN)表示暂时发送失败，需要重试，如果send返回值 <= 0, && errno != EINTR && errno != EWOULDBLOCK && errno != EAGAIN时，连接异常，需要关闭，如果send返回值 > 0则表示发送了数据？send的返回值是否这么理解，阻塞模式与非阻塞模式下send返回值=0是否都是发送失败，还是那个模式下表示暂时不可发送，需要 重发？

1. send函数

int send( SOCKET s, const char FAR *buf, int len, int flags );  

不论是客户端还是服务器端应用程序都用send函数来向TCP连接的另一端发送数据。

客户端程序一般用send函数向服务器发送请求，而服务器则通常用send函数来向客户程序发送应答。

该函数的：

第一个参数指定发送端套接字描述符；

第二个参数指明一个存放应用程序要发送数据的缓冲区；

第三个参数指明实际要发送的数据的字节数；

第四个参数一般置0。

这里只描述同步Socket的send函数的执行流程。当调用该函数时，send先比较待发送数据的长度len和套接字s的发送缓冲的长度，如果len大于s的发送缓冲区的长度，该函数返回SOCKET_ERROR；如果len小于或者等于s的发送缓冲区的长度，那么send先检查协议 是否正在发送s的发送缓冲中的数据，如果是就等待协议把数据发送完，如果协议还没有开始发送s的发送缓冲中的数据或者s的发送缓冲中没有数据，那么 send就比较s的发送缓冲区的剩余空间和len，如果len大于剩余空间大小send就一直等待协议把s的发送缓冲中的数据发送完，如果len小于剩余 空间大小send就仅仅把buf中的数据copy到剩余空间里（注意并不是send把s的发送缓冲中的数据传到连接的另一端的，而是协议传的，send仅仅是把buf中的数据copy到s的发送缓冲区的剩余空间里）。如果send函数copy数据成功，就返回实际copy的字节数，如果send在copy数据时出现错误，那么send就返回SOCKET_ERROR；如果send在等待协议传送数据时网络断开的话，那么send函数也返回SOCKET_ERROR。

要注意send函数把buf中的数据成功copy到s的发送缓冲的剩余空间里后它就返回了，但是此时这些数据并不一定马上被传到连接的另一端。如果协议在后续的传送过程中出现网络错误的话，那么下一个Socket函数就会返回SOCKET_ERROR。（每一个除send外的Socket函数在执 行的最开始总要先等待套接字的发送缓冲中的数据被协议传送完毕才能继续，如果在等待时出现网络错误，那么该Socket函数就返回 SOCKET_ERROR）

注意：在Unix系统下，如果send在等待协议传送数据时网络断开的话，调用send的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

Send函数的返回值有三类：

（1）返回值=0：

（2）返回值<0：发送失败，错误原因存于全局变量errno中

（3）返回值>0：表示发送的字节数（实际上是拷贝到发送缓冲中的字节数）

错误代码：

EBADF 参数s 非合法的socket处理代码。
EFAULT 参数中有一指针指向无法存取的内存空间
ENOTSOCK 参数s为一文件描述词，非socket。
EINTR 被信号所中断。
EAGAIN 此操作会令进程阻断，但参数s的socket为不可阻断。
ENOBUFS 系统的缓冲内存不足
ENOMEM 核心内存不足
EINVAL 传给系统调用的参数不正确。

2.  recv函数

int recv( SOCKET s,     char FAR *buf,      int len,     int flags     );   

不论是客户端还是服务器端应用程序都用recv函数从TCP连接的另一端接收数据。

该函数的：

第一个参数指定接收端套接字描述符；

第二个参数指明一个缓冲区，该缓冲区用来存放recv函数接收到的数据；

第三个参数指明buf的长度；

第四个参数一般置0。

这里只描述同步Socket的recv函数的执行流程。当应用程序调用recv函数时，recv先等待s的发送缓冲 中的数据被协议传送完毕，如果协议在传送s的发送缓冲中的数据时出现网络错误，那么recv函数返回SOCKET_ERROR，如果s的发送缓冲中没有数 据或者数据被协议成功发送完毕后，recv先检查套接字s的接收缓冲区，如果s接收缓冲区中没有数据或者协议正在接收数据，那么recv就一直等待，只到 协议把数据接收完毕。当协议把数据接收完毕，recv函数就把s的接收缓冲中的数据copy到buf中（注意协议接收到的数据可能大于buf的长度，所以 在这种情况下要调用几次recv函数才能把s的接收缓冲中的数据copy完。recv函数仅仅是copy数据，真正的接收数据是协议来完成的），recv函数返回其实际copy的字节数。如果recv在copy时出错，那么它返回SOCKET_ERROR；如果recv函数在等待协议接收数据时网络中断了，那么它返回0。

注意：在Unix系统下，如果recv函数在等待协议接收数据时网络断开了，那么调用recv的进程会接收到一个SIGPIPE信号，进程对该信号的默认处理是进程终止。

默认情况下socket是阻塞的。

阻塞与非阻塞recv返回值没有区别，都是：

<0 出错

=0 对方调用了close API来关闭连接

>0 接收到的数据大小，

特别地：返回值<0时并且(errno == EINTR || errno == EWOULDBLOCK || errno == EAGAIN)的情况下认为连接是正常的，继续接收。

只是阻塞模式下recv会一直阻塞直到接收到数据，非阻塞模式下如果没有数据就会返回，不会阻塞着读，因此需要循环读取）。

返回说明：   

（1）成功执行时，返回接收到的字节数。

（2）若另一端已关闭连接则返回0，这种关闭是对方主动且正常的关闭

（3）失败返回-1，errno被设为以下的某个值   

EAGAIN：套接字已标记为非阻塞，而接收操作被阻塞或者接收超时

EBADF：sock不是有效的描述词

ECONNREFUSE：远程主机阻绝网络连接

EFAULT：内存空间访问出错

EINTR：操作被信号中断

EINVAL：参数无效

ENOMEM：内存不足

ENOTCONN：与面向连接关联的套接字尚未被连接上

ENOTSOCK：sock索引的不是套接字

本信号在用户终端连接(正常或非正常)结束时发出, 通常是在终端的控制进程结束时, 通知同一session内的各个作业, 这时它们与控制终端不再关联。

登录Linux时，系统会分配给登录用户一个终端(Session)。在这个终端运行的所有程序，包括前台进程组和后台进程组，一般都属于这个Session。当用户退出Linux登录时，前台进程组和后台有对终端输出的进程将会收到SIGHUP信号。这个信号的默认操作为终止进程，因此前台进程组和后台有终端输出的进程就会中止。不过可以捕获这个信号，比如wget能捕获SIGHUP信号，并忽略它，这样就算退出了Linux登录，wget也能继续下载。

此外，对于与终端脱离关系的守护进程，这个信号用于通知它重新读取配置文件。

子进程结束时, 父进程会收到这个信号。

如果父进程没有处理这个信号，也没有等待(wait)子进程，子进程虽然终止，但是还会在内核进程表中占有表项，这时的子进程称为僵尸进程。这种情况我们应该避免(父进程或者忽略SIGCHILD信号，或者捕捉它，或者wait它派生的子进程，或者父进程先终止，这时子进程的终止自动由init进程来接管)。

在以上列出的信号中，程序不可捕获、阻塞或忽略的信号有：SIGKILL,SIGSTOP
不能恢复至默认动作的信号有：SIGILL,SIGTRAP
默认会导致进程流产的信号有：SIGABRT,SIGBUS,SIGFPE,SIGILL,SIGIOT,SIGQUIT,SIGSEGV,SIGTRAP,SIGXCPU,SIGXFSZ
默认会导致进程退出的信号有：SIGALRM,SIGHUP,SIGINT,SIGKILL,SIGPIPE,SIGPOLL,SIGPROF,SIGSYS,SIGTERM,SIGUSR1,SIGUSR2,SIGVTALRM
默认会导致进程停止的信号有：SIGSTOP,SIGTSTP,SIGTTIN,SIGTTOU
默认进程忽略的信号有：SIGCHLD,SIGPWR,SIGURG,SIGWINCH

此外，SIGIO在SVR4是退出，在4.3BSD中是忽略；SIGCONT在进程挂起时是继续，否则是忽略，不能被阻塞。 

在以下3个文件开头修改“#define _WIN32_WINNT 0x0603”

libevent-2.0.22-stable\event_iocp.c

libevent-2.0.22-stable\evthread_win32.c

libevent-2.0.22-stable\listener.c

3.设置nmake的环境
VC6  prefix\Microsoft Visual Studio\VC98\Bin\VCVARS32.BAT
VC8  prefix\Microsoft Visual Studio 8\VC\bin\vcvars32.bat
VC9  prefix\Microsoft Visual Studio 9.0\VC\bin\vcvars32.bat
我这里是vs2013，执行D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\vcvars32.bat
注意：这些批处理文件只会在当前进程中设置（局部的）环境变量，也就是说：
1. 用cmd（或者command）打开的命令行窗口中， 运行某个vcvar32.bat一次。
那么当前命令行窗口中就可以正常使用cl，直到关闭。

4.使用VC的nmake -f Makefile.nmake即可编译32位release模式。
如果要求编译64位的版本，需要在Makefile.nmake中添加一个LIBFLAGS选项 /MACHINE:X64
如果要加调试信息，可以在 CFLAGS中加入/Zi，32位加调试选项是 CFLAGS中加/ZI，当然要调整优化选项/Ox

1.轮叫调度（Round Robin）(简称rr)
调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
2.加权轮叫（Weighted Round Robin）（简称wrr)
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
3.最少链接（Least Connections）(LC)
调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用“最小连接”调度算法可以较好地均衡负载。
4.加权最少链接（Weighted Least Connections）(WLC)
在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
5.基于局部性的最少链接（Locality-Based Least Connections）(LBLC)
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接” 的原则选出一个可用的服务器，将请求发送到该服务器。
6.带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）(LBLCR)
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标 IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。
7.目标地址散列（Destination Hashing）(DH)
“目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
8.源地址散列（Source Hashing）(SH)
“源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

9. 最短的期望的延迟（Shortest Expected Delay Scheduling SED）(SED)
基于wlc算法。这个必须举例来说了
ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算
A(1+1)/1
B(1+2)/2
C(1+3)/3
根据运算结果，把连接交给C 。
10.最少队列调度（Never Queue Scheduling NQ）(NQ)
无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要在进行sed运算

进程异常退出

进程退出意味着进程生命期的结束，系统资源被回收，进程从操作系统环境中销毁。进程异常退出是进程在运行过程中被意外终止，从而导致进程本来应该继续执行的任务无法完成。

进程异常退出可能给软件用户造成如下负面影响：

• 软件丧失部分或者全部功能性，无法完成既定任务。
• 如果进程正在处理数据，可能造成数据损坏。
• 如果是关键软件服务，必然导致服务异常中止 , 造成无法预计的损失。
• 进程异常退出或者进程崩溃 , 也会给软件用户造成恐慌和困惑。

进程异常退出是生产环境中经常遇到的问题，它会给软件用户造成很多负面影响，所以软件开发者应当避免这种问题的出现。但是导致进程异常退出的场景和原因是多种多样的，甚至令人琢磨不透。

本文将所有可能造成进程异常退出的原因归结为两类。系统地将其分类，使读者对此类问题能有清晰的认识。对每类情况详细论述，分析根本原因，然后分析了这两类情况之间的联系，也就是信号与进程异常退出的紧密关系。希望您读完此文后，能对此类问题有更加全面、深入的理解，对调试此类问题也能有所帮助，写出更加可靠、更加稳定性、更加健壮的软件。

首先我们来看导致进程异常退出的这两类情况：

• 第一类：向进程发送信号导致进程异常退出；
• 第二类：代码错误导致进程运行时异常退出。

回页首

第一类：向进程发送信号导致进程异常退出

信号：

UNIX 系统中的信号是系统响应某些状况而产生的事件，是进程间通信的一种方式。信号可以由一个进程发送给另外进程，也可以由核发送给进程。

信号处理程序：

信号处理程序是进程在接收到信号后，系统对信号的响应。根据具体信号的涵义，相应的默认信号处理程序会采取不同的信号处理方式：

• 终止进程运行，并且产生 core dump 文件。
• 终止进程运行。
• 忽略信号，进程继续执行。
• 暂停进程运行。
• 如果进程已被暂停，重新调度进程继续执行。

前两种方式会导致进程异常退出，是本文讨论的范围。实际上，大多数默认信号处理程序都会终止进程的运行。

在进程接收到信号后，如果进程已经绑定自定义的信号处理程序，进程会在用户态执行自定义的信号处理程序；反之，内核会执行默认信号程序终止进程运行，导致进程异常退出。

所以，通过向进程发送信号可以触发默认信号处理程序，默认信号处理程序终止进程运行。在 UNIX 环境中我们有三种方式将信号发送给目标进程，导致进程异常退出。

方式一：调用函数 kill() 发送信号

我们可以调用函数 kill(pid_t pid, int sig) 向进程 ID 为 pid 的进程发送信号 sig。这个函数的原型是：

 #include <sys/types.h>   #include <signal.h>   int kill(pid_t pid, int sig);  

调用函数 kill() 后，进程进入内核态向目标进程发送指定信号；目标进程在接收到信号后，默认信号处理程序被调用，进程异常退出。

				  /* sendSignal.c, send the signal ‘ SIGSEGV ’ to specific process*/        1 #include <sys/types.h>        2 #include <signal.h>        3        4 int main(int argc, char* argv[])        5 {        6     char* pid = argv[1];        7     int PID = atoi(pid);        8        9     kill(PID, SIGSEGV);       10     return 0;       11 }  

上面的代码片段演示了如何调用 kill() 函数向指定进程发送 SIGSEGV 信号。编译并且运行程序：

 [root@machine ~]# gcc -o sendSignal sendSignal.c   [root@machine ~]# top &   [1] 22055   [root@machine ~]# ./sendSignal 22055   [1]+  Stopped                 top   [root@machine ~]# fg %1   top   Segmentation fault (core dumped)  

上面的操作中，我们在后台运行 top，进程 ID 是 22055，然后运行 sendSignal 向它发送 SIGSEGV 信号，导致 top 进程异常退出，产生 core dump 文件。

方式二：运行 kill 命令发送信号

用户可以在命令模式下运行 kill 命令向目标进程发送信号，格式为：

kill SIG*** PID

在运行 kill 命令发送信号后，目标进程会异常退出。这也是系统管理员终结某个进程的最常用方法，类似于在 Windows 平台通过任务管理器杀死某个进程。

在实现上，kill 命令也是调用 kill 系统调用函数来发送信号。所以本质上，方式一和方式二是一样的。

操作演示如下：

 [root@machine ~]# top &   [1] 22810   [root@machine ~]# kill -SIGSEGV 22810   [1]+  Stopped                 top   [root@machine ~]# fg %1   top   Segmentation fault (core dumped)  

方式三：在终端使用键盘发送信号

用户还可以在终端用键盘输入特定的字符（比如 control-C 或 control-\）向前台进程发送信号，终止前台进程运行。常见的中断字符组合是，使用 control-C 发送 SIGINT 信号，使用 control-\ 发送 SIGQUIT 信号，使用 control-z 发送 SIGTSTP 信号。

在实现上，当用户输入中断字符组合时，比如 control-C，终端驱动程序响应键盘输入，并且识别 control-C 是信号 SIGINT 的产生符号，然后向前台进程发送 SIGINT 信号。当前台进程再次被调用时就会接收到 SIGINT 信号。

使用键盘中断组合符号发送信号演示如下：

 [root@machine ~]# ./loop.sh  ( 注释：运行一个前台进程，任务是每秒钟打印一次字符串 )   i'm looping ...   i'm looping ...   i'm looping ...                 ( 注释：此时，用户输入 control-C)   [root@machine ~]#               ( 注释：接收到信号后，进程退出 )  

对这类情况的思考

这类情况导致的进程异常退出，并不是软件编程错误所导致，而是进程外部的异步信号所致。但是我们可以在代码编写中做的更好，通过调用 signal 函数绑定信号处理程序来应对信号的到来，以提高软件的健壮性。

signal 函数的原型：

 #include <signal.h>   void (*signal(int sig, void (*func)(int)))(int);  

signal 函数将信号 sig 和自定义信号处理程序绑定，即当进程收到信号 sig 时自定义函数 func 被调用。如果我们希望软件在运行时屏蔽某个信号，插入下面的代码，以达到屏蔽信号 SIGINT 的效果：

(void)signal(SIGINT, SIG_IGN)；

执行这一行代码后，当进程收到信号 SIGINT 后，进程就不会异常退出，而是会忽视这个信号继续运行。

更重要的场景是，进程在运行过程中可能会创建一些临时文件，我们希望进程在清理这些文件后再退出，避免遗留垃圾文件，这种情况下我们也可以调用 signal 函数实现，自定义一个信号处理程序来清理临时文件，当外部发送信号要求进程终止运行时，这个自定义信号处理程序被调用做清理工作。代码清单 2 是具体实现。

				       /*  bindSignal.c  */        1 #include <signal.h>        2 #include <stdio.h>        3 #include <unistd.h>        4 void cleanTask(int sig) {        5     printf( "Got the signal, deleting the tmp file\n" );        6     if( access( "/tmp/temp.lock", F_OK ) != -1 ) {        7           if( remove( "/tmp/temp.lock" ) != 0 )        8               perror( "Error deleting file" );        9           else       10               printf( "File successfully deleted\n" );       11     }       12       13     printf( "Process existing...\n" );       14     exit(0);       15 }       16       17 int main() {       18     (void) signal( SIGINT, cleanTask );       19     FILE* tmp = fopen ( "/tmp/temp.lock", "w" );       20     while(1) {       21         printf( "Process running happily\n" );       22         sleep(1);       23     }       24       25     if( tmp )       26         remove( "/tmp/temp.lock" );       27 }  运行程序：  [root@machine ~]# ./bindSignal   Process running happily   Process running happily   Process running happily                       ( 注释：此时，用户输入 control-C)   Got the signal, deleting the tmp file      ( 注释：接收到信号后，cleanTask 被调用 )   File successfully deleted                    ( 注释：cleanTask 删除临时文件 )   Process existing...                           ( 注释：进程退出 )  

回页首

第二类：编程错误导致进程运行时异常退出

相比于第一类情况，第二类情况在软件开发过程中是常客，是编程错误，进程运行过程中非法操作引起的。

操作系统和计算机硬件为应用程序的运行提供了硬件平台和软件支持，为应用程序提供了平台虚拟化，使进程运行在自己的进程空间。在进程看来，它自身独占整台系统，任何其它进程都无法干预，也无法进入它的进程空间。

但是操作系统和计算机硬件又约束每个进程的行为，使进程运行在用户态空间，控制权限，确保进程不会破坏系统资源，不会干涉进入其它进程的空间，确保进程合法访问内存。当进程尝试突破禁区做非法操作时，系统会立刻觉察，并且终止进程运行。

所以，第二类情况导致的进程异常退出，起源于进程自身的编程错误，错误的编码执行非法操作，操作系统和硬件制止它的非法操作，并且让进程异常退出。

在实现上，操作系统和计算机硬件通过异常和异常处理函数来阻止进程做非法操作。

异常和异常处理函数

当进程执行非法操作时，计算机会抛出处理器异常，系统执行异常处理函数以响应处理器异常，异常处理函数往往会终止进程运行。

广义的异常包括软中断 (soft interrupts) 和外设中断 (I/O interrupts) 。外设中断是系统外围设备发送给处理器的中断，它通知处理器 I/O 操作的状态，这种异常是外设的异步异常，与具体进程无关，所以它们不会造成进程的异常退出。本文讨论的异常是指 soft interrupts，是进程非法操作所导致的处理器异常，这类异常是进程执行非法操作所产生的同步异常，比如内存保护异常，除 0 异常，缺页异常等等。

处理器异常有很多种，系统为每个异常分配异常号，每个异常有相对应的异常处理函数。以 x86 处理器为例，除 0 操作产生 DEE 异常 (Divide Error Exception)，异常号是 0；内存非法访问产生 GPF 异常 (General Protection Fault)，异常号是 13，而缺页 (page fault) 异常的异常号是 14。当异常出现时，处理器挂起当前进程，读取异常号，然后执行相应的异常处理函数。如果异常是可修复，比如内存缺页异常，异常处理函数会修复系统错误状态，清除异常，然后重新执行一遍被中断的指令，进程继续运行；如果异常无法修复，比如内存非法访问或者除 0 操作，异常处理函数会终止进程运行，如图 2：

实例以及分析

实例一：内存非法访问

这类问题中最常见的就是内存非法访问。内存非法访问在 UNIX 平台即 segmentation fault，在 Windows 平台这类错误称为 Access violation。

内存非法访问是指：进程在运行时尝试访问尚未分配（即，没有将物理内存映射进入进程虚拟内存空间）的内存，或者进程尝试向只读内存区域写入数据。当进程执行内存非法访问操作时，内存管理单元 MMU 会产生内存保护异常 GPF(General Protection Fault)，异常号是 13。系统会立刻暂停进程的非法操作，并且跳转到 GPF 的异常处理程序，终止进程运行。

这种编程错误在编译阶段编译器不会报错，是运行时出现的错误。清单 3 是内存非法访问的一个简单实例，进程在执行第 5 行代码时执行非法内存访问，异常处理函数终止进程运行。

				       1 #include<stdio.h>        2 int main()        3 {        4      char* str = "hello";        5      str[0] = 'H';        6      return 0;        7 }  编译并运行：  [root@machine ~]# gcc demoSegfault.c -o demoSegfault   [root@machine ~]# ./demoSegfault   Segmentation fault (core dumped)   [root@machine ~]# gdb demoSegfault core.24065   ( 已省略不相干文本 )   Core was generated by `./demoSegfault'.   Program terminated with signal 11, Segmentation fault.  

分析：实例中，字符串 str 是存储在内存只读区的字符串常量，而第 5 行代码尝试更改只读区的字符，所以这是内存非法操作。

进程从开始执行到异常退出经历如下几步：

1. 进程执行第 5 行代码，尝试修改只读内存区的字符；
2. 内存管理单元 MMU 检查到这是非法内存操作，产生保护内存异常 GPF，异常号 13；
3. 处理器立刻暂停进程运行，跳转到 GPF 的异常处理函数，异常处理函数终止进程运行；
4. 进程 segmentation fault，并且产生 core dump 文件。GDB 调试结果显示，进程异常退出的原因是 segmentation fault。

实例二：除 0 操作

实例二是除 0 操作，软件开发中也会引入这样的错误。当进程执行除 0 操作时，处理器上的浮点单元 FPU(Floating-point unit) 会产生 DEE 除 0 异常 (Divide Error Exception)，异常号是 0。

				       1 #include <stdio.h>        2        3 int main()        4 {        5     int a = 1, b = 0, c;        6     printf( "Start running\n" );        7     c = a/b ;        8     printf( "About to quit\n" );        9 }  编译并运行：  [root@machine ~]# gcc -o divide0 divide0.c   [root@machine ~]# ./divide0 &   [1] 1229   [root@machine ~]# Start running   [1]+  Floating point exception(core dumped) ./divide0   [root@xbng103 ~]# gdb divide0 /corefiles/core.1229   ( 已省略不相干文本 )   Core was generated by `./divide0'.   Program terminated with signal 8, Arithmetic exception.  

分析：实例中，代码第 7 行会执行除 0 操作，导致异常出现，异常处理程序终止进程运行，并且输出错误提示：Floating point exception。

异常处理函数内幕

异常处理函数在实现上，是通过向挂起进程发送信号，进而通过信号的默认信号处理程序终止进程运行，所以异常处理函数是“间接”终止进程运行。详细过程如下：

1. 进程执行非法指令或执行错误操作；
2. 非法操作导致处理器异常产生；
3. 系统挂起进程，读取异常号并且跳转到相应的异常处理函数；
   1. 异常处理函数首先查看异常是否可以恢复。如果无法恢复异常，异常处理函数向进程发送信号。发送的信号根据异常类型而定，比如内存保护异常 GPF 相对应的信号是 SIGSEGV，而除 0 异常 DEE 相对应的信号是 SIGFPE；
   2. 异常处理函数调用内核函数 issig() 和 psig() 来接收和处理信号。内核函数 psig() 执行默认信号处理程序，终止进程运行；
4. 进程异常退出。

在此基础上，我们可以把图 2 进一步细化如下：

异常处理函数执行时会检查异常号，然后根据异常类型发送相应的信号。

再来看一下实例一（代码清单 3）的运行结果：

 [root@machine ~]# ./demoSegfault   Segmentation fault (core dumped)   [root@machine ~]# gdb demoSegfault core.24065   ( 已省略不相干文本 )   Core was generated by `./demoSegfault'.   Program terminated with signal 11, Segmentation fault.  

运行结果显示进程接收到信号 11 后异常退出，在 signal.h 的定义里，11 就是 SIGSEGV。MMU 产生内存保护异常 GPF（异常号 13）时，异常处理程序发送相应信号 SIGSEGV，SIGSEGV 的默认信号处理程序终止进程运行。

再来看实例二（代码清单 4）的运行结果

 [root@machine ~]# ./divide0 &   [1] 1229   [root@machine ~]# Start running   [1]+  Floating point exception(core dumped) ./divide0   [root@xbng103 ~]# gdb divide0 /corefiles/core.1229   ( 已省略不相干文本 )   Core was generated by `./divide0'.   Program terminated with signal 8, Arithmetic exception.  

分析结果显示进程接收到信号 8 后异常退出，在 signal.h 的定义里，8 就是信号 SIGFPE。除 0 操作产生异常（异常号 0），异常处理程序发送相应信号 SIGFPE 给挂起进程，SIGFPE 的默认信号处理程序终止进程运行。

回页首

“信号”是进程异常退出的直接原因

信号与进程异常退出有着紧密的关系：第一类情况是因为外部环境向进程发送信号，这种情况下发送的信号是异步信号，信号的到来与进程的运行是异步的；第二类情况是进程非法操作触发处理器异常，然后异常处理函数在内核态向进程发送信号，这种情况下发送的信号是同步信号，信号的到来与进程的运行是同步的。这两种情况都有信号产生，并且最终都是信号处理程序终止进程运行。它们的区别是信号产生的信号源不同，前者是外部信号源产生异步信号，后者是进程自身作为信号源产生同步信号。

所以，信号是进程异常退出的直接原因。当进程异常退出时，进程必然接收到了信号。

回页首

避免和调试进程异常退出

建议

软件开发过程中，我们应当避免进程异常退出，针对导致进程异常退出的这两类问题，对软件开发者的几点建议：

1. 通常情况无需屏蔽外部信号。信号作为进程间的一种通信方式，异步信号到来意味着外部要求进程的退出；
2. 绑定自定义信号处理程序做清理工作，当外部信号到来时，确保进程异常退出前，自定义信号处理程序被调用做清理工作，比如删除创建的临时文件。
3. 针对第二类情况，编程过程中确保进程不要做非法操作，尤其是在访问内存时，确保内存已经分配给进程（映射入进程虚拟地址空间），不要向只读区写入数据。

问题调试和定位

进程异常退出时，操作系统会产生 core dump 文件，cored ump 文件是进程异常退出前内存状态的快照，运行 GDB 分析 core dump 文件可以帮助调试和定位问题。

1) 首先，分析 core dump 查看导致进程异常退出的具体信号和退出原因。

使用 GDB 调试实例一（代码清单 3）的分析结果如下：

 [root@machine ~]# gdb demoSegfault core.24065   ( 已省略不相干文本 )   Core was generated by `./demoSegfault'.   Program terminated with signal 11, Segmentation fault.  

分析结果显示，终止进程运行的信号是 11，SIGSEGV，原因是内存非法访问。

2) 然后，定位错误代码。

在 GDB 分析 core dump 时，输入“bt”指令打印进程退出时的代码调用链，即 backtrace，就可以定位到错误代码。

用 gcc 编译程序时加入参数 -g 可以生成符号文件，帮助调试。

重新编译、执行实例一，并且分析 core dump 文件，定位错误代码：

 [root@machine ~]# gcc -o demoSegfault demoSegfault.c -g   [root@machine ~]# ./demoSegfault  &   [1] 28066   [1]+  Segmentation fault      (core dumped) ./demoSegfault   [root@machine ~]# gdb demoSegfault /corefiles/core.28066   ( 已省略不相干文本 )   Core was generated by `./demoSegfault'.   Program terminated with signal 11, Segmentation fault.   #0  0x0804835a in main () at demoSegfault.c:5   5               str[0] = 'H';   (gdb) bt   #0  0x0804835a in main () at demoSegfault.c:5   (gdb)  

在加了参数 -g 编译后，我们可以用 gdb 解析出更多的信息帮助我们调试。在输入“bt”后，GDB 输出提示错误出现在第 5 行。

3) 最后，在定位到错误代码行后，就可以很快知道根本原因，并且修改错误代码。

epoll是linux提供一种多路复用的技术，类似各个平台都支持的select，只是epoll在内核的实现做了更多地优化，可以支持比select更多的文件描述符，当然也支持 socket这种网络的文件描述符。linux上的大并发的接入服务器，目前的实现方式肯定都通过epoll实现。

epoll和线程

有很多开发人员用epoll的时候，会开多个线程来进行数据通信，比如一个线程专门accept(我个人早些年在FreeBSD用kqueue的时候，由于对内部机制没有基本了解也这样搞)，一个线程收发，或者接收和发送都用各自独立的线程。

通常情况下，accept独立线程是没必要的，accept对于内核而言，就应用程序从内核的未完成的SYN队列读取一点数据而已。具体参见 accept部分:

TCP三次握手过程与对应的Berkeley Socket APIs的介绍

收发独立成两个线程也没有必要，因为大部分的应用服务器，通常情况下，启动一个线程收发数据，最大数据的收发量瓶颈在于网卡，而不是CPU；像网游接入服务器配置一个KM的网卡，很少有游戏会申请1G的带宽，那一台机器得有多少数据输入和输出。所以我们通信线程为epoll服务器就够了。

epoll的基本原理

为了让某些朋友能读得更连惯，我还是说一下epoll基本原理。

epoll外部表现和select是一样的。他提供READ, WRITE和ERROR等事件。

大致流程像下面这样:

1. 应用注册感兴趣的事件到内核；

2. 内核在某种条件下，将事件通知应用程序；

3. 应用程序收到事件后，根据事件类型做对应的逻辑处理。

原理部分我再说一下，不容易理解的地方，包括水平触发和边缘触发，WRITE事件的事件利用(这个可以结合参考文献1的kqueue的WRITE事件，原理一致的)和修改事件的细节。

水平触发

READ事件，socket recv buff有数据，将一直向应用程序通知，直到buff为空。

WRITE事件，socket send buff从满的状态到可发送数据，将一直通知应用程序，直到buff满。

边缘触发

READ事件，socket recv buff有数据了，只通知应用一次，不管应用程序有没有调用read api，接下来都不通知了。

WRITE事件，socket send buff从满的状态到可以发送数据，只通知一次。

上面这个解释不知道大家能否理解，也只能这样说了。有疑问的做一下试验。另外，这些细节的东西，前几年固定下来后，这几年做的项目，是直接用的，也就很少在涉及细节，是凭理解和记忆写下的文字，万一有错请指正^-^。

WRITE事件的利用

这个还一下不好描述。大概描述一下，详细看参考文献1。大致这样:

1. 逻辑层写数据到应用层的发送buff，向epoll注册一下WRITE事件；

2. 这时epoll会通知应用程序一个WRITE事件；

3. 在WRITE事件响应函数里，从应用层的发送buff读数据，然后用socket send api发送。

因为我在很多实际项目中，看到大家没有利用epoll的WRITE的事件来发数据，特意地说一下。大部分的项目，是直接轮询应用程序的发送队列，我早期项目也是这么干的。

epoll的修改事件

对于这个我的映像比较深刻。epoll的修改事件比较坑爹，不能单独修改某个事件！怎么说呢？比如epoll里已经注册了READ&WRITE事件，你如果想单单重注册一下WRITE事件而且READ事件不变，epoll的epoll_ctl API是做不到的，你必须同时注册READ&WRITE，这个在下面的代码中可以看到。FreeBSD的kqueue在这一点完全满足我们程序员的要求。

抽象epoll API

我把herm socket epoll封装部分贴出来，让朋友们参考一下epoll的用法。大部分错误抛异常代码被我去掉了。

class Multiplexor
{
public:
	Multiplexor(int size, int timeout = -1, bool lt = true);
	~Multiplexor();

	void Run();
	void Register(ISockHandler* eh, MultiplexorMask mask);
	void Remove(ISockHandler* eh);
	void EnableMask(ISockHandler* eh, MultiplexorMask mask);
	void DisableMask(ISockHandler* eh, MultiplexorMask mask);
private:
	inline bool OperateHandler(int op, ISockHandler* eh, MultiplexorMask mask)
	{
		struct epoll_event evt;
		evt.data.ptr = eh;
		evt.events = mask;
		return epoll_ctl(m_epfd, op, eh->GetHandle(), &evt) != -1;
	}
private:
	int m_epfd;
	struct epoll_event* m_evts;
	int m_size;
	int m_timeout;
	__uint32_t m_otherMasks;
};
 

Multiplexor::Multiplexor(int size, int timeout, bool lt) 
{
	m_epfd = epoll_create(size);
	if (m_epfd == -1)
		throw HERM_SOCKET_EXCEPTION(ST_OTHER);
	
	m_size = size;
	m_evts = new struct epoll_event[size];

	m_timeout = timeout;

	// sys/epoll.h is no EPOLLRDHUP(0X2000), don't add EPOLLRDHUP
	m_otherMasks = EPOLLERR | EPOLLHUP;
	if (!lt)
		m_otherMasks |= EPOLLET;
}

Multiplexor::~Multiplexor()
{
	close(m_epfd);
	delete[] m_evts;
}

void Multiplexor::Run()
{
	int fds = epoll_wait(m_epfd, m_evts, m_size, m_timeout); 
	if (fds == -1)
	{
		if (errno == EINTR)
			return;
	}
	
	for (int i = 0; i < fds; ++i)
	{
		__uint32_t evts = m_evts[i].events;
		ISockHandler* eh = reinterpret_cast<ISockHandler*>(m_evts[i].data.ptr);
		int stateType = ST_SUCCESS;
		if (evts & EPOLLIN)
			stateType = eh->OnReceive();

		if (evts & EPOLLOUT)
			stateType = eh->OnSend();

		if (evts & EPOLLERR || evts & EPOLLHUP)
			stateType = ST_EXCEPT_FAILED;

		if (stateType != ST_SUCCESS)
			eh->OnError(stateType, errno);
	}
}

void Multiplexor::Register(ISockHandler* eh, MultiplexorMask mask)
{
	MultiplexorMask masks = mask | m_otherMasks;
	OperateHandler(EPOLL_CTL_ADD, eh, masks);
}

void Multiplexor::Remove(ISockHandler* eh)
{
	// Delete fd from epoll, don't need masks
	OperateHandler(EPOLL_CTL_DEL, eh, ALL_EVENTS_MASK);
}

void Multiplexor::EnableMask(ISockHandler* eh, MultiplexorMask mask)
{
	MultiplexorMask masks = mask | Herm::READ_MASK | Herm::WRITE_MASK;
	OperateHandler(EPOLL_CTL_MOD, eh, masks | m_otherMasks);
}

void Multiplexor::DisableMask(ISockHandler* eh, MultiplexorMask mask)
{
	MultiplexorMask masks = (Herm::READ_MASK | Herm::WRITE_MASK) & (~mask);
	if (!OperateHandler(EPOLL_CTL_MOD, eh, masks | m_otherMasks))
		throw HERM_SOCKET_EXCEPTION(ST_OTHER);
}

上面类就用到epoll_create(), epoll_ctl()和epoll_wait()，以及几种事件。epoll用起来比select清爽一些。

大致用法类似下面这样：

先定义一个Handler

class StreamHandler : public Herm::ISockHandler
{  
public:	
	virtual Herm::Handle GetHandle() const;
    virtual int OnReceive(int); 
	virtual int OnSend(int);
};

在OnReceive()处理收到数据的动作，在OnSend()。。。。

在通信线程中，大概类似这样的代码，实际看情况。

Multiplexor multiplexor;
StreamHandler sh;
multiplexor.Register(&sh, READ_EVT);
multiplexor.Run(...);

参考文献

1.

使用 kqueue 在 FreeBSD 上开发高性能应用服务器

FreeBSD上kqueue和epoll是类似的，有兴趣的朋友请参考。

http://blog.csdn.net/herm_lib/article/details/6047038

2.

【Herm程序员开发指导】第2章 Herm Framework和网络通信组件

http://blog.csdn.net/herm_lib/article/details/5980657

strerror() 函数依据 errno 值返回错误描述字符串，下面程序打印对照表：

01.#include <errno.h>  
02.#include <string.h>  
03.#include <stdio.h>  
04.  
05.int main()  
06.{  
07.    int i;  
08.    for(i = 0; i < 140; ++i)  
09.    {  
10.        errno = i;  
11.        printf("errno %d :\t\t%s\n",i,strerror(errno));  
12.    }  
13.    return 0;  
14.}  

errno0 : Success

errno1 : Operation not permitted

errno2 : No such file or directory

errno3 : No such process

errno4 : Interrupted system call

errno5 : Input/output error

errno6 : No such device or address

errno7 : Argument list too long

errno8 : Exec format error

errno9 : Bad file descriptor

errno10 : No child processes

errno11 : Resource temporarily unavailable

errno12 : Cannot allocate memory

errno13 : Permission denied

errno14 : Bad address

errno15 : Block device required

errno16 : Device or resource busy

errno17 : File exists

errno18 : Invalid cross-device link

errno19 : No such device

errno20 : Not a directory

errno21 : Is a directory

errno22 : Invalid argument

errno23 : Too many open files in system

errno24 : Too many open files

errno25 : Inappropriate ioctl for device

errno26 : Text file busy

errno27 : File too large

errno28 : No space left on device

errno29 : Illegal seek

errno30 : Read-only file system

errno31 : Too many links

errno32 : Broken pipe

errno33 : Numerical argument out of domain

errno34 : Numerical result out of range

errno35 : Resource deadlock avoided

errno36 : File name too long

errno37 : No locks available

errno38 : Function not implemented

errno39 : Directory not empty

errno40 : Too many levels of symbolic links

errno41 : Unknown error 41

errno42 : No message of desired type

errno43 : Identifier removed

errno44 : Channel number out of range

errno45 : Level 2 not synchronized

errno46 : Level 3 halted

errno47 : Level 3 reset

errno48 : Link number out of range

errno49 : Protocol driver not attached

errno50 : No CSI structure available

errno51 : Level 2 halted

errno52 : Invalid exchange

errno53 : Invalid request descriptor

errno54 : Exchange full

errno55 : No anode

errno56 : Invalid request code

errno57 : Invalid slot

errno58 : Unknown error 58

errno59 : Bad font file format

errno60 : Device not a stream

errno61 : No data available

errno62 : Timer expired

errno63 : Out of streams resources

errno64 : Machine is not on the network

errno65 : Package not installed

errno66 : Object is remote

errno67 : Link has been severed

errno68 : Advertise error

errno69 : Srmount error

errno70 : Communication error on send

errno71 : Protocol error

errno72 : Multihop attempted

errno73 : RFS specific error

errno74 : Bad message

errno75 : Value too large for defined datatype

errno76 : Name not unique on network

errno77 : File descriptor in bad state

errno78 : Remote address changed

errno79 : Can not access a needed sharedlibrary

errno80 : Accessing a corrupted sharedlibrary

errno81 : .lib section in a.out corrupted

errno82 : Attempting to link in too manyshared libraries

errno83 : Cannot exec a shared librarydirectly

errno84 : Invalid or incomplete multibyte orwide character

errno85 : Interrupted system call should berestarted

errno86 : Streams pipe error

errno87 : Too many users

errno88 : Socket operation on non-socket

errno89 : Destinationaddress required

errno90 : Message too long

errno91 : Protocol wrong type for socket

errno92 : Protocol not available

errno93 : Protocol not supported

errno94 : Socket type not supported

errno95 : Operation not supported

errno96 : Protocol family not supported

errno97 : Address family not supported byprotocol

errno98 : Address already in use

errno99 : Cannot assign requested address

errno100 : Network is down

errno101 : Network is unreachable

errno102 : Network dropped connection onreset

errno103 : Software caused connection abort

errno104 : Connection reset by peer

errno105 : No buffer space available

errno106 : Transport endpoint is alreadyconnected

errno107 : Transport endpoint is notconnected

errno108 : Cannot send after transportendpoint shutdown

errno109 : Too many references: cannot splice

errno110 : Connection timed out

errno111 : Connection refused

errno112 : Host is down

errno113 : No route to host

errno114 : Operation already in progress

errno115 : Operation now in progress

errno116 : Stale NFS file handle

errno117 : Structure needs cleaning

errno118 : Not a XENIX named type file

errno119 : No XENIX semaphores available

errno120 : Is a named type file

errno121 : Remote I/O error

errno122 : Disk quota exceeded

errno123 : No medium found

errno124 : Wrong medium type

errno125 : Operation canceled

errno126 : Required key not available

errno127 : Key has expired

errno128 : Key has been revoked

errno129 : Key was rejected by service

errno130 : Owner died

errno131 : State not recoverable

errno132 : Operation not possible due toRF-kill

errno133 : Unknown error 133

errno134 : Unknown error 134

errno135 : Unknown error 135

errno136 : Unknown error 136

errno137 : Unknown error 137

errno138 : Unknown error 138

errno139 : Unknown error 139

由上可见Linux对错误宏的定义。

头文件 /usr/include/asm-generic/errno-base.h 的源码：

#ifndef _ASM_GENERIC_ERRNO_BASE_H
#define _ASM_GENERIC_ERRNO_BASE_H

#define EPERM 1 /* Operation not permitted */
#define ENOENT2 /* No such file or directory */
#define ESRCH 3 /* No such process */
#define EINTR 4 /* Interrupted system call */
#define EIO 5 /* I/O error */
#define ENXIO 6 /* No such device or address */
#define E2BIG 7 /* Argument list too long */
#define ENOEXEC8 /* Exec format error */
#define EBADF 9 /* Bad file number */
#define ECHILD10 /* No child processes */
#define EAGAIN11 /* Try again */
#define ENOMEM12 /* Out of memory */
#define EACCES13 /* Permission denied */
#define EFAULT14 /* Bad address */
#define ENOTBLK15 /* Block device required */
#define EBUSY 16 /* Device or resource busy */
#define EEXIST17 /* File exists */
#define EXDEV 18 /* Cross-device link */
#define ENODEV19 /* No such device */
#define ENOTDIR20 /* Not a directory */
#define EISDIR21 /* Is a directory */
#define EINVAL22 /* Invalid argument */
#define ENFILE23 /* File table overflow */
#define EMFILE24 /* Too many open files */
#define ENOTTY25 /* Not a typewriter */
#define ETXTBSY26 /* Text file busy */
#define EFBIG 27 /* File too large */
#define ENOSPC28 /* No space left on device */
#define ESPIPE29 /* Illegal seek */
#define EROFS 30 /* Read-only file system */
#define EMLINK31 /* Too many links */
#define EPIPE 32 /* Broken pipe */
#define EDOM 33 /* Math argument out of domain of func */
#define ERANGE34 /* Math result not representable */

#endif

头文件/usr/include/asm-generic/erno.h源码：

#ifndef _ASM_GENERIC_ERRNO_H
#define _ASM_GENERIC_ERRNO_H

#include <asm-generic/errno-base.h>

#define EDEADLK35 /* Resource deadlock would occur */
#define ENAMETOOLONG36 /* File name too long */
#define ENOLCK37 /* No record locks available */
#define ENOSYS38 /* Function not implemented */
#define ENOTEMPTY39 /* Directory not empty */
#define ELOOP 40 /* Too many symbolic links encountered */
#define EWOULDBLOCKEAGAIN /* Operation would block */
#define ENOMSG42 /* No message of desired type */
#define EIDRM 43 /* Identifier removed */
#define ECHRNG44 /* Channel number out of range */
#define EL2NSYNC45 /* Level 2 not synchronized */
#define EL3HLT46 /* Level 3 halted */
#define EL3RST47 /* Level 3 reset */
#define ELNRNG48 /* Link number out of range */
#define EUNATCH49 /* Protocol driver not attached */
#define ENOCSI50 /* No CSI structure available */
#define EL2HLT51 /* Level 2 halted */
#define EBADE 52 /* Invalid exchange */
#define EBADR 53 /* Invalid request descriptor */
#define EXFULL54 /* Exchange full */
#define ENOANO55 /* No anode */
#define EBADRQC56 /* Invalid request code */
#define EBADSLT57 /* Invalid slot */

#define EDEADLOCKEDEADLK

#define EBFONT59 /* Bad font file format */
#define ENOSTR60 /* Device not a stream */
#define ENODATA61 /* No data available */
#define ETIME 62 /* Timer expired */
#define ENOSR 63 /* Out of streams resources */
#define ENONET64 /* Machine is not on the network */
#define ENOPKG65 /* Package not installed */
#define EREMOTE66 /* Object is remote */
#define ENOLINK67 /* Link has been severed */
#define EADV 68 /* Advertise error */
#define ESRMNT69 /* Srmount error */
#define ECOMM 70 /* Communication error on send */
#define EPROTO71 /* Protocol error */
#define EMULTIHOP72 /* Multihop attempted */
#define EDOTDOT73 /* RFS specific error */
#define EBADMSG74 /* Not a data message */
#define EOVERFLOW75 /* Value too large for defined data type */
#define ENOTUNIQ76 /* Name not unique on network */
#define EBADFD77 /* File descriptor in bad state */
#define EREMCHG78 /* Remote address changed */
#define ELIBACC79 /* Can not access a needed shared library */
#define ELIBBAD80 /* Accessing a corrupted shared library */
#define ELIBSCN81 /* .lib section in a.out corrupted */
#define ELIBMAX82 /* Attempting to link in too many shared libraries */
#define ELIBEXEC83 /* Cannot exec a shared library directly */
#define EILSEQ84 /* Illegal byte sequence */
#define ERESTART85 /* Interrupted system call should be restarted */
#define ESTRPIPE86 /* Streams pipe error */
#define EUSERS87 /* Too many users */
#define ENOTSOCK88 /* Socket operation on non-socket */
#define EDESTADDRREQ89 /* Destination address required */
#define EMSGSIZE90 /* Message too long */
#define EPROTOTYPE91 /* Protocol wrong type for socket */
#define ENOPROTOOPT92 /* Protocol not available */
#define EPROTONOSUPPORT93 /* Protocol not supported */
#define ESOCKTNOSUPPORT94 /* Socket type not supported */
#define EOPNOTSUPP95 /* Operation not supported on transport endpoint */
#define EPFNOSUPPORT96 /* Protocol family not supported */
#define EAFNOSUPPORT97 /* Address family not supported by protocol */
#define EADDRINUSE98 /* Address already in use */
#define EADDRNOTAVAIL99 /* Cannot assign requested address */
#define ENETDOWN100 /* Network is down */
#define ENETUNREACH101 /* Network is unreachable */
#define ENETRESET102 /* Network dropped connection because of reset */
#define ECONNABORTED103 /* Software caused connection abort */
#define ECONNRESET104 /* Connection reset by peer */
#define ENOBUFS105 /* No buffer space available */
#define EISCONN106 /* Transport endpoint is already connected */
#define ENOTCONN107 /* Transport endpoint is not connected */
#define ESHUTDOWN108 /* Cannot send after transport endpoint shutdown */
#define ETOOMANYREFS109 /* Too many references: cannot splice */
#define ETIMEDOUT110 /* Connection timed out */
#define ECONNREFUSED111 /* Connection refused */
#define EHOSTDOWN112 /* Host is down */
#define EHOSTUNREACH113 /* No route to host */
#define EALREADY114 /* Operation already in progress */
#define EINPROGRESS115 /* Operation now in progress */
#define ESTALE116 /* Stale NFS file handle */
#define EUCLEAN117 /* Structure needs cleaning */
#define ENOTNAM118 /* Not a XENIX named type file */
#define ENAVAIL119 /* No XENIX semaphores available */
#define EISNAM120 /* Is a named type file */
#define EREMOTEIO121 /* Remote I/O error */
#define EDQUOT122 /* Quota exceeded */

#define ENOMEDIUM123 /* No medium found */
#define EMEDIUMTYPE124 /* Wrong medium type */
#define ECANCELED125 /* Operation Canceled */
#define ENOKEY126 /* Required key not available */
#define EKEYEXPIRED127 /* Key has expired */
#define EKEYREVOKED128 /* Key has been revoked */
#define EKEYREJECTED129 /* Key was rejected by service */

/* for robust mutexes */
#define EOWNERDEAD130 /* Owner died */
#define ENOTRECOVERABLE131 /* State not recoverable */

#define ERFKILL 132/* Operation not possible due to RF-kill */

#endif

简而言之,产生段错误就是访问了错误的内存段，一般是你没有权限，或者根本就不存在对应的物理内存,尤其常见的是访问0地址.

一般来说,段错误就是指访问的内存超出了系统所给这个程序的内存空间，通常这个值是由gdtr来保存的，他是一个48位的寄存器，其中的32位是保存由它指向的gdt表，后13位保存相应于gdt的下标，最后3位包括了程序是否在内存中以及程序的在cpu中的运行级别,指向的gdt是由以64位为一个单位的表，在这张表中就保存着程序运行的代码段以及数据段的起始地址以及与此相应的段限和页面交换还有程序运行级别还有内存粒度等等的信息。一旦一个程序发生了越界访问，cpu就会产生相应的异常保护，于是segmentation fault就出现了.

在编程中以下几类做法容易导致段错误,基本是是错误地使用指针引起的

1)访问系统数据区，尤其是往  系统保护的内存地址写数据
   最常见就是给一个指针以0地址
2)内存越界(数组越界，变量类型不一致等) 访问到不属于你的内存区域

解决方法

我们在用C/C++语言写程序的时侯，内存管理的绝大部分工作都是需要我们来做的。实际上，内存管理是一个比较繁琐的工作，无论你多高明，经验多丰富，难 免会在此处犯些小错误，而通常这些错误又是那么的浅显而易于消除。但是手工“除虫”（debug），往往是效率低下且让人厌烦的，本文将就"段错误"这个 内存访问越界的错误谈谈如何快速定位这些"段错误"的语句。
下面将就以下的一个存在段错误的程序介绍几种调试方法：

1  dummy_function (void)      2  {      3          unsigned char *ptr = 0x00;      4          *ptr = 0x00;      5  }      6      7  int main (void)      8  {      9          dummy_function ();     10     11          return 0;     12  }

作为一个熟练的C/C++程序员，以上代码的bug应该是很清楚的，因为它尝试操作地址为0的内存区域，而这个内存区域通常是不可访问的禁区，当然就会出错了。我们尝试编译运行它:

xiaosuo@gentux test $ ./a.out 段错误

果然不出所料，它出错并退出了。
1.利用gdb逐步查找段错误:
这种方法也是被大众所熟知并广泛采用的方法，首先我们需要一个带有调试信息的可执行程序，所以我们加上“-g -rdynamic"的参数进行编译，然后用gdb调试运行这个新编译的程序,具体步骤如下:

xiaosuo@gentux test $ gcc -g -rdynamic d.c xiaosuo@gentux test $ gdb ./a.out GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) r Starting program: /home/xiaosuo/test/a.out Program received signal SIGSEGV, Segmentation fault. 0x08048524 in dummy_function () at d.c:4 4               *ptr = 0x00; (gdb)

哦？！好像不用一步步调试我们就找到了出错位置d.c文件的第4行，其实就是如此的简单。
从这里我们还发现进程是由于收到了SIGSEGV信号而结束的。通过进一步的查阅文档(man 7 signal)，我们知道SIGSEGV默认handler的动作是打印”段错误"的出错信息，并产生Core文件，由此我们又产生了方法二。
2.分析Core文件：
Core文件是什么呢？

The  default action of certain signals is to cause a process to terminate and produce a core dump file, a disk file containing an image of the process's memory  at the time of termination.  A list of the signals which cause a process to dump core can be found in signal(7).

以 上资料摘自man page(man 5 core)。不过奇怪了，我的系统上并没有找到core文件。后来，忆起为了渐少系统上的拉圾文件的数量（本人有些洁癖，这也是我喜欢Gentoo的原因 之一），禁止了core文件的生成，查看了以下果真如此，将系统的core文件的大小限制在512K大小，再试:

xiaosuo@gentux test $ ulimit -c 0 xiaosuo@gentux test $ ulimit -c 1000 xiaosuo@gentux test $ ulimit -c 1000 xiaosuo@gentux test $ ./a.out 段错误 (core dumped) xiaosuo@gentux test $ ls a.out  core  d.c  f.c  g.c  pango.c  test_iconv.c  test_regex.c

core文件终于产生了，用gdb调试一下看看吧:

xiaosuo@gentux test $ gdb ./a.out core GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". warning: Can't read pathname for load map: 输入/输出错误. Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Core was generated by `./a.out'. Program terminated with signal 11, Segmentation fault. #0  0x08048524 in dummy_function () at d.c:4 4               *ptr = 0x00;

哇，好历害，还是一步就定位到了错误所在地，佩服一下Linux/Unix系统的此类设计。
接着考虑下去，以前用windows系统下的ie的时侯，有时打开某些网页，会出现“运行时错误”，这个时侯如果恰好你的机器上又装有windows的编译器的话，他会弹出来一个对话框，问你是否进行调试，如果你选择是，编译器将被打开，并进入调试状态，开始调试。
Linux下如何做到这些呢？我的大脑飞速地旋转着，有了，让它在SIGSEGV的handler中调用gdb，于是第三个方法又诞生了:
3.段错误时启动调试:

#include <stdio.h> #include <stdlib.h> #include <signal.h> #include <string.h> void dump(int signo) {         char buf[1024];         char cmd[1024];         FILE *fh;         snprintf(buf, sizeof(buf), "/proc/%d/cmdline", getpid());         if(!(fh = fopen(buf, "r")))                 exit(0);         if(!fgets(buf, sizeof(buf), fh))                 exit(0);         fclose(fh);         if(buf[strlen(buf) - 1] == '\n')                 buf[strlen(buf) - 1] = '\0';         snprintf(cmd, sizeof(cmd), "gdb %s %d", buf, getpid());         system(cmd);         exit(0); }         void dummy_function (void) {         unsigned char *ptr = 0x00;         *ptr = 0x00; }         int main (void) {         signal(SIGSEGV, &dump);         dummy_function ();         return 0; }

编译运行效果如下:

xiaosuo@gentux test $ gcc -g -rdynamic f.c xiaosuo@gentux test $ ./a.out GNU gdb 6.5 Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Attaching to program: /home/xiaosuo/test/a.out, process 9563 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 0xffffe410 in __kernel_vsyscall () (gdb) bt #0  0xffffe410 in __kernel_vsyscall () #1  0xb7ee4b53 in waitpid () from /lib/libc.so.6 #2  0xb7e925c9 in strtold_l () from /lib/libc.so.6 #3  0x08048830 in dump (signo=11) at f.c:22 #4  <signal handler called> #5  0x0804884c in dummy_function () at f.c:31 #6  0x08048886 in main () at f.c:38

怎么样？是不是依旧很酷？
以上方法都是在系统上有gdb的前提下进行的，如果没有呢？其实glibc为我们提供了此类能够dump栈内容的函数簇，详见/usr/include/execinfo.h（这些函数都没有提供man page，难怪我们找不到），另外你也可以通过gnu的手册进行学习。
4.利用backtrace和objdump进行分析:
重写的代码如下:

#include <execinfo.h> #include <stdio.h> #include <stdlib.h> #include <signal.h> /* A dummy function to make the backtrace more interesting. */         void dummy_function (void) {         unsigned char *ptr = 0x00;         *ptr = 0x00; } void dump(int signo) {         void *array[10];         size_t size;         char **strings;         size_t i;         size = backtrace (array, 10);         strings = backtrace_symbols (array, size);         printf ("Obtained %zd stack frames.\n", size);         for (i = 0; i < size; i++)                 printf ("%s\n", strings[i]);         free (strings);         exit(0); }         int main (void) {         signal(SIGSEGV, &dump);         dummy_function ();         return 0; }

编译运行结果如下：

xiaosuo@gentux test $ gcc -g -rdynamic g.c xiaosuo@gentux test $ ./a.out Obtained 5 stack frames. ./a.out(dump+0x19) [0x80486c2] [0xffffe420] ./a.out(main+0x35) [0x804876f] /lib/libc.so.6(__libc_start_main+0xe6) [0xb7e02866] ./a.out [0x8048601]

这次你可能有些失望,似乎没能给出足够的信息来标示错误,不急,先看看能分析出来什么吧,用objdump反汇编程序,找到地址0x804876f对应的代码位置:

xiaosuo@gentux test $ objdump -d a.out

8048765:       e8 02 fe ff ff          call   804856c <signal@plt>  804876a:       e8 25 ff ff ff          call   8048694 <dummy_function>  804876f:       b8 00 00 00 00          mov    $0x0,%eax  8048774:       c9                      leave

我们还是找到了在哪个函数(dummy_function)中出错的,信息已然不是很完整,不过有总比没有好的啊!
后记:
本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。

部分资料来源于xiaosuo @ cnblog.cn, 特此致谢

作者:upsdn整理   更新日期:2006-11-03
来源:upsdn.net   浏览次数:



其它调试办法

• 添加日志 

            在Linux上的使用开源C++日志库---log4cplus 

linux下追踪函数调用堆栈

一般察看函数运行时堆栈的方法是使用GDB之类的外部调试器,但是,有些时候为了分析程序的BUG,(主要针对长时间运行程序的分析),在程序出错时打印出函数的调用堆栈是非常有用的。

 在头文件"execinfo.h"中声明了三个函数用于获取当前线程的函数调用堆栈

 Function: int backtrace(void **buffer,int size)

 该函数用与获取当前线程的调用堆栈,获取的信息将会被存放在buffer中,它是一个指针列表。参数 size 用来指定buffer中可以保存多少个void* 元素。函数返回值是实际获取的指针个数,最大不超过size大小

 在buffer中的指针实际是从堆栈中获取的返回地址,每一个堆栈框架有一个返回地址

 注意某些编译器的优化选项对获取正确的调用堆栈有干扰,另外内联函数没有堆栈框架;删除框架指针也会使无法正确解析堆栈内容

 Function: char ** backtrace_symbols (void *const *buffer, int size)

 backtrace_symbols将从backtrace函数获取的信息转化为一个字符串数组. 参数buffer应该是从backtrace函数获取的数组指针,size是该数组中的元素个数(backtrace的返回值)

 函数返回值是一个指向字符串数组的指针,它的大小同buffer相同.每个字符串包含了一个相对于buffer中对应元素的可打印信息.它包括函数名，函数的偏移地址,和实际的返回地址

 现在,只有使用ELF二进制格式的程序和苦衷才能获取函数名称和偏移地址.在其他系统,只有16进制的返回地址能被获取.另外,你可能需要传递相应的标志给链接器,以能支持函数名功能(比如,在使用GNU ld的系统中,你需要传递(-rdynamic))

 该函数的返回值是通过malloc函数申请的空间,因此调用这必须使用free函数来释放指针.

 注意:如果不能为字符串获取足够的空间函数的返回值将会为NULL

 Function:void backtrace_symbols_fd (void *const *buffer, int size, int fd)

 backtrace_symbols_fd与backtrace_symbols 函数具有相同的功能,不同的是它不会给调用者返回字符串数组,而是将结果写入文件描述符为fd的文件中,每个函数对应一行.它不需要调用malloc函数,因此适用于有可能调用该函数会失败的情况。

3.执行./configure 在此可以指定安装目录加 --prefix=/usr/local指定

4.make

5.make install如果目录没有权限是需要超级用户的

　　epoll则没有这样的限制，epoll支持的最大链接数是最大可打开的文件的数目。epoll只对活跃的socket进行操作——这是因为epoll是根据每个fd上面的callback函数实现的。那么，只有活跃的socket才会主动地调用callback函数。在一个高速的LAN环境，如果几乎所有的socket都是活跃的，epoll的效率比select会稍微有下降。

　　使用mmap加速内核与用户空间的消息传递。无论select，poll都需要内核把FD消息通知给用户空间，如何避免不必要的内存拷贝，在这点上epoll通过内核与用户空间mmap同一块内存空间实现的。

　　epoll有两种工作方式LT（level triggered）和ET（edge triggered）。

　　LT（level triggered）是缺省的工作方式，支持block和non-block socket。在这种模式下，内核告诉你一个文件描述符已经就绪了，然后对这个描述符进行io操作。如果你不作任何操作，内核还会继续通知你的。所以，这种模式编程出错可能性要小一点。传统的select/poll都是这种模型的代表。

　　ET（edge triggered）高速工作方式，只支持no-block描述符。在这种模式下，当描述符由未就绪变为就绪时，内核通过epoll告诉你。然后它假设你知道文件描述符已经就绪，并且不再为那个描述符发送更多的就绪通知，直到你做了某些操作导致描述符不再是就绪状态了（比如，你在发送、接收或者接收请求、或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK错误）。但是请注意，如果一直不对这个fd作io操作（从而导致它再次变成未就绪），内核不会发送更多的通知（only once），不过在TCP协议中，ET模式的加速效果仍需要更多benchmark确认。

epoll接口

int epoll_create(int size)

创建一个epoll句柄，size告诉内核这个监听的数目一共有多大。这个参数不同于select的第一个参数，给出最大的fd+1值。需要注意的是，当创建好epoll句柄后，它就会占用一个fd值，在linux下如果查看/proc/prodid/fd/能够看到这个fd的，所以使用完epoll后，必须调用close关闭。

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)

epoll事件注册函数，它不同于select是在监听事件时告诉内核要监听什么类型的事件，而是在这里先注册要监听的事件类型。

epfd：epoll描述符

op：EPOLL_CTL_ADD 注册新的fd

EPOLL_CTL_MOD 修改已注册的fd的监听事件

EPOLL_CTL_DEL 从epfd中删除一个fd

struct epoll_event {

__uint32_t event; /* EPOLLIN 可以读（包括对端socket正常关闭）

EPOLLOUT 可以写

EPOLLPRI 有紧急数据可读（这里应该表示有带外数据到来）

EPOLLERR 对应文件描述符发生错误

EPOLLHUP 对应的文件描述符被挂断

EPOLLET ET工作模式

EPOLLONESHOT 只监听一次事件，当监听完这次事件后，还需要继续监听的话，需要再次把fd加入到监听队列里。

epoll_data_t data; /* user data */

};

typedef union epoll_data {
void ptr;
int fd;
__uint32_t u32;
__uint64_t u64;
} epoll_data_t;

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)

等待事件的产生，类似于select。

events，从内核得到事件的总和

maxevents，告诉内核这个events有多大，不能大于epoll_create size 值

timeout，超时时间（毫秒）。0：立即返回，-1 不确定或永久阻塞

返回，0：超时；否则 事件个数

假如有这样一个例子：
1. 我们已经把一个用来从管道中读取数据的文件句柄(RFD)添加到epoll描述符
2. 这个时候从管道的另一端被写入了2KB的数据
3. 调用epoll_wait(2)，并且它会返回RFD，说明它已经准备好读取操作
4. 然后我们读取了1KB的数据
5. 调用epoll_wait(2)......

Edge Triggered 工作模式：
如果我们在第1步将RFD添加到epoll描述符的时候使用了EPOLLET标志，那么在第5步调用epoll_wait(2)之后将有可能会挂起，因为剩余的数据还存在于文件的输入缓冲区内，而且数据发出端还在等待一个针对已经发出数据的反馈信息。只有在监视的文件句柄上发生了某个事件的时候 ET 工作模式才会汇报事件。因此在第5步的时候，调用者可能会放弃等待仍在存在于文件输入缓冲区内的剩余数据。在上面的例子中，会有一个事件产生在RFD句柄上，因为在第2步执行了一个写操作，然后，事件将会在第3步被销毁。因为第4步的读取操作没有读空文件输入缓冲区内的数据，因此我们在第5步调用 epoll_wait(2)完成后，是否挂起是不确定的。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。最好以下面的方式调用ET模式的epoll接口，在后面会介绍避免可能的缺陷。
i 基于非阻塞文件句柄
ii 只有当read(2)或者write(2)返回EAGAIN时才需要挂起，等待。但这并不是说每次read()时都需要循环读，直到读到产生一个EAGAIN才认为此次事件处理完成，当read()返回的读到的数据长度小于请求的数据长度时，就可以确定此时缓冲中已没有数据了，也就可以认为此事读事件已处理完成。

另外，当使用epoll的ET模型来工作时，当产生了一个EPOLLIN事件后，
读数据的时候需要考虑的是当recv()返回的大小如果等于请求的大小，那么很有可能是缓冲区还有数据未读完，也意味着该次事件还没有处理完，所以还需要再次读取：
while(rs)
{
buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
if(buflen < 0)
{
// 由于是非阻塞的模式,所以当errno为EAGAIN时,表示当前缓冲区已无数据可读
// 在这里就当作是该次事件已处理处.
if(errno == EAGAIN)
break;
else
return;
}
else if(buflen == 0)
{
// 这里表示对端的socket已正常关闭.
}
if(buflen == sizeof(buf)
rs = 1; // 需要再次读取
else
rs = 0;
}


还有，假如发送端流量大于接收端的流量(意思是epoll所在的程序读比转发的socket要快),由于是非阻塞的socket,那么send()函数虽然返回,但实际缓冲区的数据并未真正发给接收端,这样不断的读和发，当缓冲区满后会产生EAGAIN错误(参考man send),同时,不理会这次请求发送的数据.所以,需要封装socket_send()的函数用来处理这种情况,该函数会尽量将数据写完再返回，返回-1表示出错。在socket_send()内部,当写缓冲已满(send()返回-1,且errno为EAGAIN),那么会等待后再重试.这种方式并不很完美,在理论上可能会长时间的阻塞在socket_send()内部,但暂没有更好的办法.

ssize_t socket_send(int sockfd, const char* buffer, size_t buflen)
{
ssize_t tmp;
size_t total = buflen;
const char *p = buffer;

while(1)
{
tmp = send(sockfd, p, total, 0);
if(tmp < 0)
{
// 当send收到信号时,可以继续写,但这里返回-1.
if(errno == EINTR)
return -1;

// 当socket是非阻塞时,如返回此错误,表示写缓冲队列已满,
// 在这里做延时后再重试.
if(errno == EAGAIN)
{
usleep(1000);
continue;
}

return -1;
}

if((size_t)tmp == total)
return buflen;

total -= tmp;
p += tmp;
}

return tmp;
}

（一）发送时

　　当客户通过Socket提供的send函数发送大的数据包时，就可能返回一个EAGAIN的错误。该错误产生的原因是由于send 函数中的size变量大小超过了tcp_sendspace的值。tcp_sendspace定义了应用在调用send之前能够在kernel中缓存的数据量。当应用程序在socket中设置了O_NDELAY或者O_NONBLOCK属性后，如果发送缓存被占满，send就会返回EAGAIN的错误。

　　为了消除该错误，有三种方法可以选择：
　　1.调大tcp_sendspace，使之大于send中的size参数
　　---no -p -o tcp_sendspace=65536

　　2.在调用send前，在setsockopt函数中为SNDBUF设置更大的值

　　3.使用write替代send，因为write没有设置O_NDELAY或者O_NONBLOCK

（二）接收时

接收数据时常遇到Resource temporarily unavailable的提示，errno代码为11(EAGAIN)。这表明你在非阻塞模式下调用了阻塞操作，在该操作没有完成就返回这个错误，这个错误不会破坏socket的同步，不用管它，下次循环接着recv就可以。对非阻塞socket而言，EAGAIN不是一种错误。在VxWorks和Windows上，EAGAIN的名字叫做EWOULDBLOCK。其实这算不上错误，只是一种异常而已。

　　另外，如果出现EINTR即errno为4，错误描述Interrupted system call，操作也应该继续。

　　最后，如果recv的返回值为0，那表明对方已将连接断开，我们的接收操作也应该结束。

（三）以下是另一种解释

假如发送端流量大于接收端的流量(意思是epoll所在的程序读比转发的socket要快),由于是非阻塞的socket,那么send()函数虽然返回,但实际缓冲区的数据并未真正发给接收端,这样不断的读和发，当缓冲区满后会产生EAGAIN错误(参考man send),同时,不理会这次请求发送的数据.所以,

size_t socket_send(int sockfd, const char* buffer, size_t buflen)
{
	size_t tmp;
	size_t total = buflen;
	const char *p = buffer;

	while(1)
	{
		tmp = send(sockfd, p, total, 0);

		if(tmp < 0)
		{
			// 当send收到信号时,可以继续写,但这里返回-1.
			if(errno == EINTR)
			{
				return -1;
			}

			// 当socket是非阻塞时,如返回此错误,表示写缓冲队列已满,
			// 在这里做延时后再重试.
			if(errno == EAGAIN)
			{
				usleep(1000);
				continue;
			}

			return -1;
		}

		if((size_t)tmp == total)
		{
			return buflen;
		}

		total -= tmp;
		p += tmp;
	}

	return tmp;
}
 

本文识别那些隐患并向您显示如何避开它们。

隐患 1．忽略返回状态

第一个隐患很明显，但它是开发新手最容易犯的一个错误。如果您忽略函数的返回状态，当它们失败或部分成功的时候，您也许会迷失。反过来，这可能传播错误，使定位问题的源头变得困难。

捕获并检查每一个返回状态，而不是忽略它们。考虑清单 1 显示的例子，一个套接字 send 函数。

int status, sock, mode;
/* Create a new stream (TCP) socket */
sock = socket( AF_INET, SOCK_STREAM, 0 );
...
status = send( sock, buffer, buflen, MSG_DONTWAIT );
if (status == -1) {
  /* send failed */
  printf( "send failed: %s\n", strerror(errno) );
} else {
  /* send succeeded -- or did it? */
}

清单 1 探究一个函数片断，它完成套接字 send 操作（通过套接字发送数据）。函数的错误状态被捕获并测试，但这个例子忽略了 send 在无阻塞模式（由 MSG_DONTWAIT 标志启用）下的一个特性。

send API 函数有三类可能的返回值：

• 如果数据成功地排到传输队列，则返回 0。
• 如果排队失败，则返回 -1（通过使用 errno 变量可以了解失败的原因）。
• 如果不是所有的字符都能够在函数调用时排队，则最终的返回值是发送的字符数。

由于 send 的 MSG_DONTWAIT 变量的无阻塞性质，函数调用在发送完所有的数据、一些数据或没有发送任何数据后返回。在这里忽略返回状态将导致不完全的发送和随后的数据丢失。

回页首

隐患 2．对等套接字闭包

UNIX 有趣的一面是您几乎可以把任何东西看成是一个文件。文件本身、目录、管道、设备和套接字都被当作文件。这是新颖的抽象，意味着一整套的 API 可以用在广泛的设备类型上。

考虑 read API 函数，它从文件读取一定数量的字节。read 函数返回读取的字节数（最高为您指定的最大值）；或者 -1，表示错误；或者 0，如果已经到达文件末尾。

如果在一个套接字上完成一个 read 操作并得到一个为 0 的返回值，这表明远程套接字端的对等层调用了 close API 方法。该指示与文件读取相同 —— 没有多余的数据可以通过描述符读取（参见 清单 2）。

int sock, status;
sock = socket( AF_INET, SOCK_STREAM, 0 );
...
status = read( sock, buffer, buflen );
if (status > 0) {
  /* Data read from the socket */
} else if (status == -1) {
  /* Error, check errno, take action... */
} else if (status == 0) {
  /* Peer closed the socket, finish the close */
  close( sock );
  /* Further processing... */
}

同样，可以用 write API 函数来探测对等套接字的闭包。在这种情况下，接收 SIGPIPE 信号，或如果该信号阻塞，write 函数将返回 -1 并设置 errno 为 EPIPE。

回页首

隐患 3．地址使用错误（EADDRINUSE）

您可以使用 bind API 函数来绑定一个地址（一个接口和一个端口）到一个套接字端点。可以在服务器设置中使用这个函数，以便限制可能有连接到来的接口。也可以在客户端设置中使用这个函数，以便限制应当供出去的连接所使用的接口。bind 最常见的用法是关联端口号和服务器，并使用通配符地址（INADDR_ANY），它允许任何接口为到来的连接所使用。

bind 普遍遭遇的问题是试图绑定一个已经在使用的端口。该陷阱是也许没有活动的套接字存在，但仍然禁止绑定端口（bind 返回 EADDRINUSE），它由 TCP 套接字状态 TIME_WAIT 引起。该状态在套接字关闭后约保留 2 到 4 分钟。在 TIME_WAIT 状态退出之后，套接字被删除，该地址才能被重新绑定而不出问题。

等待 TIME_WAIT 结束可能是令人恼火的一件事，特别是如果您正在开发一个套接字服务器，就需要停止服务器来做一些改动，然后重启。幸运的是，有方法可以避开 TIME_WAIT 状态。可以给套接字应用 SO_REUSEADDR 套接字选项，以便端口可以马上重用。

考虑清单 3 的例子。在绑定地址之前，我以 SO_REUSEADDR 选项调用 setsockopt。为了允许地址重用，我设置整型参数（on）为 1 （不然，可以设为 0 来禁止地址重用）。

int sock, ret, on;
struct sockaddr_in servaddr;
/* Create a new stream (TCP) socket */
sock = socket( AF_INET, SOCK_STREAM, 0 ):
/* Enable address reuse */
on = 1;
ret = setsockopt( sock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on) );
/* Allow connections to port 8080 from any available interface */
memset( &servaddr, 0, sizeof(servaddr) );
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl( INADDR_ANY );
servaddr.sin_port = htons( 45000 );
/* Bind to the address (interface/port) */
ret = bind( sock, (struct sockaddr *)&servaddr, sizeof(servaddr) );

在应用了 SO_REUSEADDR 选项之后，bind API 函数将允许地址的立即重用。

回页首

隐患 4．发送结构化数据

套接字是发送无结构二进制字节流或 ASCII 数据流（比如 HTTP 上的 HTTP 页面，或 SMTP 上的电子邮件）的完美工具。但是如果试图在一个套接字上发送二进制数据，事情将会变得更加复杂。

比如说，您想要发送一个整数：您可以肯定，接收者将使用同样的方式来解释该整数吗？运行在同一架构上的应用程序可以依赖它们共同的平台来对该类型的数据做出相同的解释。但是，如果一个运行在高位优先的 IBM PowerPC 上的客户端发送一个 32 位的整数到一个低位优先的 Intel x86，那将会发生什么呢？字节排列将引起不正确的解释。

通过套接字发送一个 C 结构会怎么样呢？这里，也会遇到麻烦，因为不是所有的编译器都以相同的方式排列一个结构的元素。结构也可能被压缩以便使浪费的空间最少，这进一步使结构中的元素错位。

幸好，有解决这个问题的方案，能够保证两端数据的一致解释。过去，远程过程调用（Remote Procedure Call，RPC）套装工具提供所谓的外部数据表示（External Data Representation，XDR）。XDR 为数据定义一个标准的表示来支持异构网络应用程序通信的开发。

现在，有两个新的协议提供相似的功能。可扩展标记语言/远程过程调用（XML/RPC）以 XML 格式安排 HTTP 上的过程调用。数据和元数据用 XML 进行编码并作为字符串传输，并通过主机架构把值和它们的物理表示分开。SOAP 跟随 XML-RPC，以更好的特性和功能扩展了它的思想。参见 参考资料 小节，获取更多关于每个协议的信息。

回页首

隐患 5．TCP 中的帧同步假定

TCP 不提供帧同步，这使得它对于面向字节流的协议是完美的。这是 TCP 与 UDP（User Datagram Protocol，用户数据报协议）的一个重要区别。UDP 是面向消息的协议，它保留发送者和接收者之间的消息边界。TCP 是一个面向流的协议，它假定正在通信的数据是无结构的，如图 1 所示。

图 1 的上部说明一个 UDP 客户端和服务器。左边的对等层完成两个套接字的写操作，每个 100 字节。协议栈的 UDP 层追踪写的数量，并确保当右边的接收者通过套接字获取数据时，它以同样数量的字节到达。换句话说，为读者保留了写者提供的消息边界。

现在，看图 1 的底部．它为 TCP 层演示了相同粒度的写操作。两个独立的写操作（每个 100 字节）写入流套接字。但在本例中，流套接字的读者得到的是 200 字节。协议栈的 TCP 层聚合了两次写操作。这种聚合可以发生在 TCP/IP 协议栈的发送者或接收者中任何一方。重要的是，要注意到聚合也许不会发生 —— TCP 只保证数据的有序发送。

对大多数开发人员来说，该陷阱会引起困惑。您想要获得 TCP 的可靠性和 UDP 的帧同步。除非改用其他的传输协议，比如流传输控制协议（STCP），否则就要求应用层开发人员来实现缓冲和分段功能。

回页首

调试套接字应用程序的工具

GNU/Linux 提供几个工具，它们可以帮助您发现套接字应用程序中的一些问题。此外，使用这些工具还有教育意义，而且能够帮助解释应用程序和 TCP/IP 协议栈的行为。在这里，您将看到对几个工具的概述。查阅下面的 参考资料 了解更多的信息。

查看网络子系统的细节

netstat 工具提供查看 GNU/Linux 网络子系统的能力。使用 netstat，可以查看当前活动的连接（按单个协议进行查看），查看特定状态的连接（比如处于监听状态的服务器套接字）和许多其他的信息。清单 4 显示了 netstat 提供的一些选项和它们启用的特性。

View all TCP sockets currently active
$ netstat --tcp
View all UDP sockets
$ netstat --udp
View all TCP sockets in the listening state
$ netstat --listening
View the multicast group membership information
$ netstat --groups
Display the list of masqueraded connections
$ netstat --masquerade
View statistics for each protocol
$ netstat --statistics

尽管存在许多其他的实用程序，但 netstat 的功能很全面，它覆盖了 route、ifconfig 和其他标准 GNU/Linux 工具的功能。

监视流量

可以使用 GNU/Linux 的几个工具来检查网络上的低层流量。tcpdump 工具是一个比较老的工具，它从网上“嗅探”网络数据包，打印到 stdout 或记录在一个文件中。该功能允许查看应用程序产生的流量和 TCP 生成的低层流控制机制。一个叫做 tcpflow 的新工具与 tcpdump 相辅相成，它提供协议流分析和适当地重构数据流的方法，而不管数据包的顺序或重发。清单 5 显示 tcpdump 的两个用法模式。

Display all traffic on the eth0 interface for the local host
$ tcpdump -l -i eth0
Show all traffic on the network coming from or going to host plato
$ tcpdump host plato
Show all HTTP traffic for host camus
$ tcpdump host camus and (port http)
View traffic coming from or going to TCP port 45000 on the local host
$ tcpdump tcp port 45000

tcpdump 和 tcpflow 工具有大量的选项，包括创建复杂过滤表达式的能力。查阅下面的 参考资料 获取更多关于这些工具的信息。

tcpdump 和 tcpflow 都是基于文本的命令行工具。如果您更喜欢图形用户界面（GUI），有一个开放源码工具 Ethereal 也许适合您的需要。Ethereal 是一个专业的协议分析软件，它可以帮助调试应用层协议。它的插入式架构（plug-in architecture）可以分解协议，比如 HTTP 和您能想到的任何协议（写本文的时候共有 637 个协议）。

回页首

总结

套接字编程是容易而有趣的，但是您要避免引入错误或至少使它们容易被发现，这就需要考虑本文中描述的这 5 个常见的陷阱，并且采用标准的防错性程序设计实践。GNU/Linux 工具和实用程序还可以帮助发现一些程序中的小问题。记住：在查看实用程序的帮助手册时候，跟踪相关的或“请参见”工具。您也许会发现一个必要的新工具。

参考资料

学习

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
  
• TCP 状态机有 11 个状态。参见 W. Richard Steven 的 illustration from TCP/IP Illustrated, Volume 1 一书。
  
  
• 在 Wikipedia 上探究 Endianness 的历史和含意。
  
  
• 了解更多关于 IBM 的开放式、可伸缩和可定制的 Power Architecture 的信息。
  
  
• 从 Programming in C 课件阅读 RPC/XDR 简介。
  
  
• 获取更多关于 XML-RPC 以及在 Java™ 应用程序中如何使用它的信息，请阅读 “Java 编程中的 XML-RPC” （developerWorks，2004 年 1 月）。
  
  
• SOAP 以 XML-RPC 的特性为基础。请在 SoapWare.Org 上查找规范、工具、教程和文章。
  
  
• SCTP 兼有 TCP 和 UDP 的特性，以及可用性和可靠性。
  
  
• 教程 “Linux Socket 编程，第一部分” （developerWorks，2003 年 10 月）讲解如何开始套接字编程以及如何构建一个通过 TCP/IP 连接的 echo 服务器和客户端。“Linux Socket 编程，第二部分” （developerWorks，2004 年 1 月）集中讨论 UDP 并且讲解如何用 C 和 Python 编写 UDP 套接字应用程序（尽管代码会翻译为其他语言）。
  
  
• netstat 手册页 提供有关各种使用 netstat 的方法的细节。
  
  
• BSD Sockets Programming from a Multilanguage Perspective （作者 M. Tim Jones），用 6 种不同的语言介绍了套接字编程的技巧。
  
  
• 在 developerWorks Linux 专区 上查找更多为 Linux 开发人员提供的参考资料。
  
  

获得产品和技术

• tcpdump 和 tcpflow 实用程序可以用来监控网络流量。
  
  
• Ethereal network protocol analyzer 提供 tcpdump 的功能，它具有图形用户界面和可伸缩的插入式架构。
  
  
• 免费索取 SEK for Linux（两张 DVD），它包含来自 DB2®、Lotus®、Rational®、Tivoli® 以及 WebSphere® 的最新 IBM 试用软件的 Linux 版本。
  
  
• 用 IBM 试用软件 在 Linux 上构建您的下一个开发项目，可以直接在 developerWorks 上下载。
  
  
  

讨论

• 通过参与 developerWorks blog 加入 developerWorks 社区。
  

1. SO_DEBUG，打开或关闭调试信息。
   当option_value不等于0时，打开调试信息，否则，关闭调试信息。它实际所做的工作是在sock->sk->sk_flag中置SOCK_DBG(第10)位，或清SOCK_DBG位。
2. SO_REUSEADDR，打开或关闭地址复用功能。
   当option_value不等于0时，打开，否则，关闭。它实际所做的工作是置sock->sk->sk_reuse为1或0。
3. SO_DONTROUTE，打开或关闭路由查找功能。
   当option_value不等于0时，打开，否则，关闭。它实际所做的工作是在sock->sk->sk_flag中置或清SOCK_LOCALROUTE位。
4. SO_BROADCAST，允许或禁止发送广播数据。
   当option_value不等于0时，允许，否则，禁止。它实际所做的工作是在sock->sk->sk_flag中置或清SOCK_BROADCAST位。
5. SO_SNDBUF，设置发送缓冲区的大小。
   发送缓冲区的大小是有上下限的，其上限为256 * (sizeof(struct sk_buff) + 256)，下限为2048字节。该操作将sock->sk->sk_sndbuf设置为val * 2，之所以要乘以2，是防
   止大数据量的发送，突然导致缓冲区溢出。最后，该操作完成后，因为对发送缓冲的大小作了改变，要检查sleep队列，如果有进程正在等待写，将它们唤醒。
6. SO_RCVBUF，设置接收缓冲区的大小。
   接收缓冲区大小的上下限分别是：256 * (sizeof(struct sk_buff) + 256)和256字节。该操作将sock->sk->sk_rcvbuf设置为val * 2。
7. SO_KEEPALIVE，套接字保活。
   如果协议是TCP，并且当前的套接字状态不是侦听(listen)或关闭(close)，那么，当option_value不是零时，启用TCP保活定时器，否则关闭保活定时器。对于所有协议，该操
   作都会根据option_value置或清sock->sk->sk_flag中的 SOCK_KEEPOPEN位。
8. SO_OOBINLINE，紧急数据放入普通数据流。
   该操作根据option_value的值置或清sock->sk->sk_flag中的SOCK_URGINLINE位。
9. SO_NO_CHECK，打开或关闭校验和。
   该操作根据option_value的值，设置sock->sk->sk_no_check。
10. SO_PRIORITY，设置在套接字发送的所有包的协议定义优先权。Linux通过这一值来排列网络队列。
    这个值在0到6之间（包括0和6），由option_value指定。赋给sock->sk->sk_priority。
11. SO_LINGER，如果选择此选项, close或 shutdown将等到所有套接字里排队的消息成功发送或到达延迟时间后>才会返回. 否则, 调用将立即返回。
    该选项的参数（option_value)是一个linger结构：
    struct linger {
    int l_onoff; /* 延时状态（打开/关闭） */
    int l_linger; /* 延时多长时间 */
    };
    如果linger.l_onoff值为0(关闭），则清sock->sk->sk_flag中的SOCK_LINGER位；否则，置该位，并赋sk->sk_lingertime值为linger.l_linger。
12. SO_PASSCRED，允许或禁止SCM_CREDENTIALS 控制消息的接收。
    该选项根据option_value的值，清或置sock->sk->sk_flag中的SOCK_PASSCRED位。
13. SO_TIMESTAMP，打开或关闭数据报中的时间戳接收。
    该选项根据option_value的值，清或置sock->sk->sk_flag中的SOCK_RCVTSTAMP位，如果打开，则还需设sock->sk->sk_flag中的SOCK_TIMESTAMP位，同时，将全局变量
    netstamp_needed加1。
14. SO_RCVLOWAT，设置接收数据前的缓冲区内的最小字节数。
    在Linux中，缓冲区内的最小字节数是固定的，为1。即将sock->sk->sk_rcvlowat固定赋值为1。
15. SO_RCVTIMEO，设置接收超时时间。
    该选项最终将接收超时时间赋给sock->sk->sk_rcvtimeo。
16. SO_SNDTIMEO，设置发送超时时间。
    该选项最终将发送超时时间赋给sock->sk->sk_sndtimeo。
17. SO_BINDTODEVICE，将套接字绑定到一个特定的设备上。
    该选项最终将设备赋给sock->sk->sk_bound_dev_if。
18. SO_ATTACH_FILTER和SO_DETACH_FILTER。
    关于数据包过滤，它们最终会影响sk->sk_filter。
    以上所介绍的都是在SOL_SOCKET层的一些套接字选项，如果超出这个范围，给出一些不在这一level的选项作为参数，最终会得到- ENOPROTOOPT的返回值。但以上的分析仅限
    于这些选项对sock-sk的值的影响，这些选项真正如何发挥作用，我们的探索道路将漫漫其修远。

mmap 的第三个参数指定对内存区域的保护，由标记读、写、执行权限的 PROT_READ、PROT_WRITE 和 PROT_EXEC 按位与操作获得，或者是限制没有访问权限的 PROT_NONE。如果程序尝试在不允许这些权限的本地内存上操作，它将被 SIGSEGV 信号（Segmentation fault，段错误）终止。

在内存映射完成后，这些权限仍可以被 mprotect 系统调用所修改。mprotect 的参数分别为内存区间的地址，区间的大小，新的保护标志设置。所指定的内存区间必须包含整个页：区间地址必须和整个系统页大小对齐，而区间长度必须是页大小的整数倍。这些页的保护标记被这里指定的新保护模式替换。

获得页面对齐的内存
应注意的是， malloc 返回的内存区域通常并不与内存页面对齐，甚至在内存的大小是页大小整数倍的情况下也一样。如果您想保护从 malloc 获得的内存，您不得不分配一个更大的内存区域并在其中找到一个与页对齐的区间。
您可以选择使用 mmap 系统调用来绕过 malloc 并直接从 Linux 内核中分配页面对齐内存。

mmap通过映射 /dev/zero 来分配内存页。内存将被初始化为可读和可写模式。

int fd = open (“/dev/zero”, O_RDONLY);
char* memory = mmap (NULL, page_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
close (fd);

然后，您的程序可以使用 mprotect 把它变成只读：

mprotect (memory, page_size, PROT_READ);

有一种监控内存访问的高级技巧，可以通过利用 mmap 和 mprotect 保护目标内存区间，然后当程序访问时候接收并处理 Linux 系统发送的 SIGSEGV 信号。代码 展示了这个技巧。

代码使用mprotect检测内存访问

#include <fcntl.h>
#include <signal.h>
#include <stdio.h>
#include <string.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>

static int alloc_size;
static char* memory;

void segv_handler (int signal_number)
{
  printf (“memory accessed!\n”);
  mprotect (memory, alloc_size, PROT_READ | PROT_WRITE);
}

int main ()
{
  int fd;
  struct sigaction sa;

  /* 初始化segv_handler为SIGSEGV的句柄。*/
  memset (&sa, 0, sizeof (sa));
  sa.sa_handler = &segv_handler;
  sigaction (SIGSEGV, &sa, NULL);

  /* 使用映射/dev/zero分配内存页。最初映射的内存为只写。*/
  alloc_size = getpagesize ();
  fd = open (“/dev/zero”, O_RDONLY);
  memory = mmap (NULL, alloc_size, PROT_WRITE, MAP_PRIVATE, fd, 0);
  close (fd);
  /* 写页来获得一个私有复制。 */
  memory[0] = 0;
  /* 使内存为不可写。 */
  mprotect (memory, alloc_size, PROT_NONE);

  /* 写分配内存区域。 */
  memory[0] = 1;
  /* 所有工作都结束；unmap内存映射。 */
  printf (“all done\n”);
  munmap (memory, alloc_size);

  return 0;
}

上述程序按照如下步骤执行：

1. 程序为 SIGSEGV 建立一个信号处理句柄。
2. 程序通过映射 /dev/zero 分配一个内存分页，然后通过写入数据的方式获得一个私有复本。
3. 程序通过调用带 PROT_NONE 权限的 mprotect 保护了内存。
4. 当程序在后续执行中写入内存时，Linux 向进程发送 SIGSEGV，这个信号被 segv_handler 句柄接收处理。这个句柄将解除内存保护，因而程序内存访问得以继续。
5. 当信号句柄执行完成时，程序控制权返回 main 函数，程序将使用 munmap 来释放内存。

memcached全面剖析–3.memcached的删除机制和发展方向

$ memcached -M -m 1024

 Byte/     0       |       1       |       2       |       3       |   
    /              |               |               |               |   
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0/ HEADER                                                        /   
   /                                                               /   
   /                                                               /   
   /                                                               /   
   +---------------+---------------+---------------+---------------+
 24/ COMMAND-SPECIFIC EXTRAS (as needed)                           /   
  +/  (note length in th extras length header field)               /   
   +---------------+---------------+---------------+---------------+
  m/ Key (as needed)                                               /   
  +/  (note length in key length header field)                     /   
   +---------------+---------------+---------------+---------------+
  n/ Value (as needed)                                             /   
  +/  (note length is total body length header field, minus        /   
  +/   sum of the extras and key length body fields)               /   
   +---------------+---------------+---------------+---------------+
  Total 24 bytes

Request Header

 Byte/     0       |       1       |       2       |       3       |
    /              |               |               |               |
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0| Magic         | Opcode        | Key length                    |
   +---------------+---------------+---------------+---------------+
  4| Extras length | Data type     | Reserved                      |
   +---------------+---------------+---------------+---------------+
  8| Total body length                                             |
   +---------------+---------------+---------------+---------------+
 12| Opaque                                                        |
   +---------------+---------------+---------------+---------------+
 16| CAS                                                           |
   |                                                               |
   +---------------+---------------+---------------+---------------+

Response Header

 Byte/     0       |       1       |       2       |       3       |
    /              |               |               |               |
   |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7|
   +---------------+---------------+---------------+---------------+
  0| Magic         | Opcode        | Key Length                    |
   +---------------+---------------+---------------+---------------+
  4| Extras length | Data type     | Status                        |
   +---------------+---------------+---------------+---------------+
  8| Total body length                                             |
   +---------------+---------------+---------------+---------------+
 12| Opaque                                                        |
   +---------------+---------------+---------------+---------------+
 16| CAS                                                           |
   |                                                               |
   +---------------+---------------+---------------+---------------+

gcc是linux的唯一编译器，没有gcc就没有linux，gcc的重要性就不可言喻啦。居然这么重要，那就很值得我们来好好研究下啦。好啦，开始我们的gcc之旅吧！

首先消除gcc和g++误区吧。
gcc和g++都是GNU(组织)的一个编译器。

误区一:gcc只能编译c代码,g++只能编译c++代码

两者都可以，但是请注意：
1.后缀为.c的，gcc把它当作是C程序，而g++当作是c++程序；后缀为.cpp的，两者都会认为是c++程序，注意，虽然c++是c的超集，但是两者对语法的要求是有区别的，例如：
#include <stdio.h>
int main(int argc, char* argv[]) {
if(argv == 0) return;
printString(argv);
return;
}
int printString(char* string) {
sprintf(string, "This is a test."n");
}
如果按照C的语法规则，OK，没问题，但是，一旦把后缀改为cpp，立刻报三个错：“printString未定义”；
“cannot convert `char**' to `char*”；
”return-statement with no value“；
分别对应前面红色标注的部分。可见C++的语法规则更加严谨一些。
2.编译阶段，g++会调用gcc，对于c++代码，两者是等价的，但是因为gcc命令不能自动和C＋＋程序使用的库联接，所以通常用g++来完成链接，为了统一起见，干脆编译/链接统统用g++了，这就给人一种错觉，好像cpp程序只能用g++似的。

误区二:gcc不会定义__cplusplus宏，而g++会

实际上，这个宏只是标志着编译器将会把代码按C还是C++语法来解释，如上所述，如果后缀为.c，并且采用gcc编译器，则该宏就是未定义的，否则，就是已定义。

误区三:编译只能用gcc，链接只能用g++

严格来说，这句话不算错误，但是它混淆了概念，应该这样说：编译可以用gcc/g++，而链接可以用g++或者gcc -lstdc++。因为gcc命令不能自动和C＋＋程序使用的库联接，所以通常使用g++来完成联接。但在编译阶段，g++会自动调用gcc，二者等价。

误区四:extern "C"与gcc/g++有关系

实际上并无关系，无论是gcc还是g++，用extern "c"时，都是以C的命名方式来为symbol命名，否则，都以c++方式命名。试验如下：
me.h：
extern "C" void CppPrintf(void);

me.cpp:
#include <iostream>
#include "me.h"
using namespace std;
void CppPrintf(void)
{
cout << "Hello"n";
}

test.cpp:
#include <stdlib.h>
#include <stdio.h>
#include "me.h"
int main(void)
{
CppPrintf();
return 0;
}

1. 先给me.h加上extern "C"，看用gcc和g++命名有什么不同

[root@root G++]# g++ -S me.cpp
[root@root G++]# less me.s
.globl _Z9CppPrintfv //注意此函数的命名
.type CppPrintf, @function
[root@root GCC]# gcc -S me.cpp
[root@root GCC]# less me.s
.globl _Z9CppPrintfv //注意此函数的命名
.type CppPrintf, @function
完全相同！

2. 去掉me.h中extern "C"，看用gcc和g++命名有什么不同

[root@root GCC]# gcc -S me.cpp
[root@root GCC]# less me.s
.globl _Z9CppPrintfv //注意此函数的命名
.type _Z9CppPrintfv, @function
[root@root G++]# g++ -S me.cpp
[root@root G++]# less me.s
.globl _Z9CppPrintfv //注意此函数的命名
.type _Z9CppPrintfv, @function
完全相同！

相对于静态函数库，动态函数库在编译的时候并没有被编译进目标代码中，而只是作些标记。然后在程序开始启动运行的时候，动态地加载所需模块，因此动态函数库所产生的可执行文件比较小。由于函数库没有被整合进你的程序，而是程序运行时动态的申请并调用，所以程序的运行环境中必须提供相应的库。动态函数库的改变并不影响你的程序，所以动态函数库的升级比较方便。

2.命名：
静态库的名字一般为libxxxx.a，其中xxxx是该lib的名称。
动态库的名字一般为libxxxx.so.major.minor，xxxx是该lib的名称，major是主版本号，minor是副版本号。版本号也可以没有，一般都会建立个没有版本号的软连接文件链接到全名的库文件。

3.创建：
无论静态库还是动态库，创建都分为两步，第一步创建目标文件，第二步生产库。
1).静态库的创建：
#gcc -c test.c -o test.o
#ar rcs libtest.a test.o
名字为libtest.a的静态库就生产了，其中选项：
r 表明将模块加入到静态库中；
c 表示创建静态库；
s 表示生产索引；
还有更多选项像增加、删除库中的目标文件，包括将静态库解包等可以通过man来获得。
2).动态库的创建：
#gcc -fPIC -c test.c -o test.c
#gcc --share test.o -o libtest.so
-fPIC 为了跨平台

4.使用：
编译链接目标程序的方法是一样的：
#gcc main.c -L. -ltest -o main
-L.指定现在本目录下搜索库，如果没有，会到系统默认的目录下搜索，一般为/lib、/usr/lib下。
对于静态库，这个步骤之后就可以将libtest.a库删掉，因为它已经被编译进了目标程序，不再需要它了。
而对于动态库，libtest.so库只是在目标程序里做了标记，在运行程序时才会动态加载，那么从哪加载呢？加载目录会由/etc/ld.so.conf来指定，一般默认是/lib、/usr/lib，所以要想让动态库顺利加载，你可以将库文件copy到上面的两个目录下，或者设置export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/XXX/YYY，后面为你自己动态库的目录，再或者修改/etc/ld.so.conf文件，把库所在的路径加到文件末尾，并执行ldconfig刷新。这样，加入的目录下的所有库文件都可见。

另外还有个文件需要了解/etc/ld.so.cache，里面保存了常用的动态函数库，且会先把他们加载到内存中，因为内存的访问速度远远大于硬盘的访问速度，这样可以提高软件加载动态函数库的速度了。

最后提一点，当同一目录下既有动态库又有静态库，并且两个库的名字相同时，编译时会如何链接呢？

gcc编译时默认都是动态链接，如果要指定优先链接静态库，需要指定参数static。