古老的信号量机制，80年代初，从System V体系中产生，称为System v信号量。90年代，Posix标准确立，其中的信号量称为posix信号量。当前linux系统支持这两种信号量（man semget/ man sem_post)。System v信号量为有名信号量，可以用于多进程间的互斥同步。posix信号量分有名和无名两种，当前linux只支持无名信号量，可以用于多线程之间的互斥同步，通过共享内存也可以用于多进程之间。
信号量属于内核级别的互斥同步机制，相关调用总是陷入内核态，属于功能强大/重量级的实现。

   二 spinlock机制
多核SMP的cpu流行后，出现的新的互斥同步机制。spinlock实现原理为用户态循环尝试机制，不陷入内核态进行线程切换。spinlock的原子性通过CAS(CompareAndSwap)原语实现。使用spinlock时，应该保证保护区间内代码执行迅速，不应该存在io等耗时操作。
多核系统下，针对可快速执行的保护区使用用户态循环尝试机制，可以保证执行线程不需要引起上下文切换即可快速执行通过，这种机制也被形象的称为lock-free机制。我们可以这样理解：lock-free机制即为循环尝试，spinlock是它的具体实现。

spinlock的实现有多种，常见的有pthread_spin_lock，该spinlock无限制循环尝试，在多核环境下并且保护区代码执行迅速时，执行线程很快可以拿到锁，但当单核环境或者保护区代码执行慢速时，则会耗尽该线程拥有的时间片之后交出cpu，造成cpu的浪费。另一常见的spinlock是boost智能指针中的实现，进行3次无间断的循环CAS原语判断，之后若再次失败，则调用sleep族函数，交出cpu执行权，待再次分配到cpu时间片后继续进行CAS原语判断操作。

   三 mutex机制
mutex属于os之上的再次封装实现。在linux2.6内核上，线程库为nptl，其中的mutex基于futex机制实现，它的实现原理，简单说就是spinlock+semaphore，首先使用spinlock尝试，可以拿到锁则直接向下执行，拿不到锁则执行semaphore机制，陷入内核态，进入线程切换。
在多核环境下，当mutex保护的代码段内无io操作，执行很快时，大多数情况下通过spinlock都可拿到锁，不需要陷入内核态。

  四 为智能指针正名(boost)
智能指针的引用计数仅仅为一个整型变量的增减，属于执行迅速的典型，使用spinlock机制保护，最新boost版本中仅仅是spinlock，而非mutex。从性能角度说，使用智能指针的现象是cpu略微上升（循环尝试导致），而并发量/单个请求的响应时间并无明显影响。proactor机制实现的网络层，智能指针基本无法绕过，刻意避免带来的只能是丑陋的代码和维护量的上升。但线程之间尽量避免传递指针（智能指针），通过传递id等代替。
智能指针有它使用的场景，不能滥用，也不能刻意避免。

from:

http://www.cppblog.com/CppExplore/archive/2010/08/28/125067.html

　　怎样产生僵尸进程的：

　　一个进程在调用exit命令结束自己的生命的时候，其实它并没有真正的被销毁，而是留下一个称为僵尸进程（Zombie）的数据结构（系统调用 exit，它的作用是使进程退出，但也仅仅限于将一个正常的进程变成一个僵尸进程，并不能将其完全销毁）。在Linux进程的状态中，僵尸进程是非常特殊的一种，它已经放弃了几乎所有内存空间，没有任何可执行代码，也不能被调度，仅仅在进程列表中保留一个位置，记载该进程的退出状态等信息供其他进程收集，除此之外，僵尸进程不再占有任何内存空间。它需要它的父进程来为它收尸，如果他的父进程没安装SIGCHLD信号处理函数调用wait或waitpid()等待子进程结束，又没有显式忽略该信号，那么它就一直保持僵尸状态，如果这时父进程结束了，那么init进程自动会接手这个子进程，为它收尸，它还是能被清除的。但是如果如果父进程是一个循环，不会结束，那么子进程就会一直保持僵尸状态，这就是为什么系统中有时会有很多的僵尸进程。

　　Linux系统对运行的进程数量有限制，如果产生过多的僵尸进程占用了可用的进程号，将会导致新的进程无法生成。这就是僵尸进程对系统的最大危害。

　　僵尸进程实例：

　　/*-----zombie1.c-----*/

　　#include "sys/types.h"

　　#include "sys/wait.h"

　　#include "stdio.h"

　　#include "unistd.h"

　　int main(int argc, char* argv[])

　　{

　　        while(1)

　　        {

　　               pid_t chi = fork();

　　                if(chi == 0)

　　                {

　　                        execl("/bin/bash","bash","-c","ls",NULL);

　　                }

　　                sleep(2);

　　}

　　会不停地产生僵死进程ls；

　　/*-----zombie2.c-----*/

　　#include <stdio.h>

　　#include<sys/types.h>

　　main()

　　{

　        　if(!fork())

　        　{

　                　printf("child pid=%d\n", getpid());

                　　exit(0);

　        　}

　        　/*wait();*/

　        　/*waitpid(-1,NULL,0);*/

　        　sleep(60);

　        　printf("parent pid=%d \n", getpid());

　        　exit(0);

　　}

　　60s内会不断产生僵尸进程，直到父进程exit(0);

　　如果在调用wait/waitpid来为子进程收尸，就不会产生僵尸进程了。

　　PS：运行例子，先gcc zombie1.c -o zombie编译，然后运行zombie；

　　然后可以可用ps -ef来查看是否产生了僵尸进程。

　　怎么查看僵尸进程：

　　利用命令ps，可以看到有标记为Z的进程就是僵尸进程。

　　怎样来清除僵尸进程：

　　1.改写父进程，在子进程死后要为它收尸。具体做法是接管SIGCHLD信号。子进程死后，会发送SIGCHLD信号给父进程，父进程收到此信 号后，执行 waitpid()函数为子进程收尸。这是基于这样的原理：就算父进程没有调用wait，内核也会向它发送SIGCHLD消息，尽管对的默认处理是忽略， 如果想响应这个消息，可以设置一个处理函数。

　　ps auwx

　　发现僵尸进程

　　a all w/ tty, including other users 所有窗口和终端，包括其他用户的进程

　　u user-oriented 面向用户(用户友好)

　　-w,w wide output 宽格式输出

　　x processes w/o controlling ttys

　　在僵尸进程后面 会标注

　　ps axf

　　看进程树，以树形方式现实进程列表

　　ps axm

　　会把线程列出来,在linux下进程和线程是统一的，是轻量级进程的两种方式。

　　ps axu

　　显示进程的详细状态

　　killall

　　kill -15

　　kill -9

　　一般都不能杀掉 defunct进程

　　用了kill -15,kill -9以后 之后反而会多出更多的僵尸进程

　　kill -kill pid

　　fuser -k pid

　　可以考虑杀死他的parent process，

　　kill -9 他的parent process

　　=========================================== 一个已经终止,但是其父进程尚未对其进行善后处理（获取终止子进程的有关信息、释放它仍占用的资源）的进程被称为僵死进程(Zombie Process)。

　　避免zombie的方法：

　　1)在SVR4中，如果调用signal或sigset将SIGCHLD的配置设置为忽略,则不会产生僵死子进程。另外,使用SVR4版的 sigaction,则可设置SA_NOCLDWAIT标志以避免子进程僵死。

　　Linux中也可使用这个，在一个程序的开始调用这个函数

　　signal(SIGCHLD,SIG_IGN);

　　2)调用fork两次。程序8 - 5 实现了这一点。

　　3)用waitpid等待子进程返回.

　　===========================================

　　zombie进程是僵死进程。防止它的办法，一是用wait,waitpid之类的函数获得进程的终止状态，以释放资源。另一个是fork两次

　　===========================================

　　defunct进程只是在process table里还有一个记录，其他的资源没有占用，除非你的系统的process个数的限制已经快超过了，zombie进程不会有更多的坏处。

　　可能唯一的方法就是reboot系统可以消除zombie进程。

　　===========================================

　　任何程序都有僵尸状态，它占用一点内存资源(也就是进程表里还有一个记录)，仅仅是表象而已不必害怕。如果程序有问题有机会遇见，解决大批量僵尸简单有效的办法是重起。kill是无任何效果的

　　fork与zombie/defunct"

　　在Unix下的一些进程的运作方式。当一个进程死亡时,它并不是完全的消失了。进程终止,它不再运行,但是还有一些残留的小东西等待父进程收 回。这些残留的东西包括子进程的返回值和其他的一些东西。当父进程 fork()一个子进程后,它必须用 wait() 或者 waitpid() 等待子进程退出。正是这个 wait() 动作来让子进程的残留物消失。

　　自然的，在上述规则之外有个例外:父进程可以忽略 SIGCLD 软中断而不必要 wait()。可以这样做到(在支持它的系统上,比如Linux):

　　main()

　　{

　　signal(SIGCLD, SIG_IGN); /* now I don't have to wait()! */

　　fork();

　　fork(); /* Rabbits, rabbits, rabbits! */

　　｝

　　现在，子进程死亡时父进程没有 wait()，通常用 ps 可以看到它被显示为“”。它将永远保持这样 直到 父进程 wait()，或者按以下方法处理。

　　这里是你必须知道的另一个规则:当父进程在它wait()子进程之前死亡了(假定它没有忽略 SIGCLD),子进程将把 init(pid1)进程作为它的父进程。如果子进程工作得很好并能够控制，这并不是问题。但如果子进程已经是defunct，我们就有了一点小麻烦。 看，原先的父进程不可能再 wait()，因为它已经消亡了。这样，init 怎么知道 wait() 这些zombie 进程。

　　答案：不可预料的。在一些系统上，init周期性的破坏掉它所有的defunct进程。在另外一些系统中,它干脆拒绝成为任何defunct进 程的父进程，而是马上毁灭它们。如果你使用上述系统的一种,可以写一个简单的循环，用属于init的defunct进程填满进程表。这大概不会令你的系统 管理员很高兴吧?

　　你的任务：确定你的父进程不要忽略 SIGCLD，也不要 wait() 它 fork() 的所有进程。不过，你也未必 要总是这样做（比如，你要起一个 daemon 或是别的什么东西）,但是你必须小心编程，如果你是一个 fork()的新手。另外，也不要在心理上有任何束缚。

　　总结：

　　子进程成为 defunct 直到父进程 wait()，除非父进程忽略了 SIGCLD 。

　　更进一步，父进程没有 wait() 就消亡（仍假设父进程没有忽略 SIGCLD ）的子进程（活动的或者 defunct）成为 init 的子进程，init 用重手法处理它们。

from:

http://linux.chinaitlab.com/administer/818916.html

info threads
显示当前可调试的所有线程，每个线程会有一个GDB为其分配的ID，后面操作线程的时候会用到这个ID。
前面有*的是当前调试的线程。

thread ID
切换当前调试的线程为指定ID的线程。

break thread_test.c:123 thread all
在所有线程中相应的行上设置断点

thread apply ID1 ID2 command
让一个或者多个线程执行GDB命令command。

thread apply all command
让所有被调试线程执行GDB命令command。

set scheduler-locking off|on|step
估计是实际使用过多线程调试的人都可以发现，在使用step或者continue命令调试当前被调试线程的时候，其他线程也是同时执行的，怎么只让被调试程序执行呢？通过这个命令就可以实现这个需求。
off 不锁定任何线程，也就是所有线程都执行，这是默认值。
on 只有当前被调试程序会执行。
step 在单步的时候，除了next过一个函数的情况(熟悉情况的人可能知道，这其实是一个设置断点然后continue的行为)以外，只有当前线程会执行。

在介绍完基本的多线程调试命令后，大概介绍一下GDB多线程调试的实现思路。

比较主要的代码是thread.c，前面介绍的几个命令等都是在其中实现。
thread_list这个表存储了当前可调试的所有线程的信息。
函数add_thread_silent或者add_thread(不同版本GDB不同)用来向thread_list列表增加一个线程的信息。
函数delete_thread用来向thread_list列表删除一个线程的信息。
上面提到的这2个函数会被有线程支持的target调用，用来增加和删除线程，不同的OS对线程的实现差异很大，这么实现比较好的保证了GDB多线程调试支持的扩展性。
函数info_threads_command是被命令info threads调用的，就是显示thread_list列表的信息。
函数thread_command是被命令thread调用，切换当前线程最终调用的函数是switch_to_thread，这个函数会先将当前调试线程变量inferior_ptid，然后对寄存器和frame缓冲进行刷新。
函数thread_apply_command被命令thread apply调用，这个函数的实际实现其实很简单，就是先切换当前线为指定线程，然后调用函数execute_command调用指定函数。

比较特别的是set scheduler-locking没有实现在thread.c中，而是实现在控制被调试程序执行的文件infrun.c中。
对 其的设置会保存到变量scheduler_mode中，而实际使用这个变量的函数只有用来令被调试程序执行的函数resume。在默认情况下， 传递给target_resume的变量是resume_ptid，默认情况下其的值为RESUME_ALL，也就是告诉target程序执行的时候所有 被调试线程都要被执行。而当scheduler_mode设置为只让当前线程执行的时候，resume_ptid将被设置为inferior_ptid， 这就告诉target只有inferior_ptid的线程会被执行。

最后特别介绍一下Linux下多线程的支持，基本的调试功能在linux-nat.c中，这里有对Linux轻量级别进程本地调试的支持。但是其 在调试多线程程序的时候，还需要对pthread调试的支持，这个功能实现在linux-thread-db.c中。对pthread的调试要通过调用 libthread_db库来支持。
这里有一个单独的target"multi-thread"，这个target有2点很特别:
第 一，一般target的装载是在调用相关to_open函数的时候调用push_target进行装载。而这个target则不同，在其初始化 的时候，就注册了函数thread_db_new_objfile到库文件attach事件中。这样当GDB为调试程序的动态加载库时候attach库文 件的时候，就会调用这个函数thread_db_new_objfile。这样当GDB装载libpthread库的时候，最终会装载 target"multi-thread"。
第二，这个target并没有像大部分target那样自己实现了全部调试功能，其配合linux-nat.c的代码的功能，这里有一个target多层结构的设计，要介绍的比较多，就不详细介绍了。

最后介绍一下我最近遇见的一个多线程调试和解决。

基本问题是在一个Linux环境中，调试多线程程序不正常，info threads看不到多线程的信息。
我先用命令 maintenance print target-stack看了一下target的装载情况，发现target"multi-thread"没有被装载，用GDB对GDB进行调试，发现在 函数check_for_thread_db在调用libthread_db中的函数td_ta_new的时候，返回了TD_NOLIBTHREAD，所 以没有装载target"multi-thread"。
在时候我就怀疑是不是libpthread有问题，于是检查了一下发现了问题，这个环 境中的libpthread是被strip过的，我想可能 就是以为这个影响了td_ta_new对libpthread符号信息的获取。当我换了一个没有strip过的libpthread的时候，问题果然解决 了。
最终我的解决办法是拷贝了一个.debug版本的libpthread到lib目录中，问题解决了。  多线程如果dump，多为段错误，一般都涉及内存非法读写。可以这样处理，使用下面的命令打开系统开关，让其可以在死掉的时候生成core文件。  
ulimit -c unlimited
这样的话死掉的时候就可以在当前目录看到core.pid(pid为进程号)的文件。接着使用gdb:
gdb ./bin ./core.pid
进去后，使用bt查看死掉时栈的情况，在使用frame命令。

还有就是里面某个线程停住，也没死，这种情况一般就是死锁或者涉及消息接受的超时问题(听人说的，没有遇到过)。遇到这种情况，可以使用：
gcore pid （调试进程的pid号）
手动生成core文件，在使用pstack(linux下好像不好使)查看堆栈的情况。如果都看不出来，就仔细查看代码，看看是不是在if，return，break，continue这种语句操作是忘记解锁，还有嵌套锁的问题，都需要分析清楚了。

from:

http://blog.chinaunix.net/u3/91335/showart.php?id=2249238

012号与013 号程序，分别是关于消息队列和共享内存的

/*********************程序相关信 息*********************
程序编号：012
程序编写起始日期：2008.11.1
程序编写完成日期：2008.11.1
程序修改日 期：                                   修改备注：
程序目的：学习linux消息队列通信
所用主要函 数：msgget(),msgsnd(),msgrcv(),msgctl()
程序 存疑：
程序完成地点： 宿舍内
*********************程序相关信息*********************/
#include<sys/types.h>
#include<sys/ipc.h>
#include<sys/msg.h>
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
int main()
{
    int pid,msqid;//后者为消息队列识别代号
    struct msgbuf
    {
        long mtype;//消息类型
        char mtext[20];//消息内容
    }send_buf,receive_buf;
    if((msqid=msgget(IPC_PRIVATE,0700))<0)//建立消息队列
    {
        printf("msgget建立消息队列失败。\n");
        exit(1);
    }
    else
        printf("msgget建立消息队列成功，该消息队列识别代号为%d。\n",msqid);
    if((pid=fork())<0)
    {
        printf("fork()函数调用失败！\n");
        exit(2);
    }
    else if(pid>0)//父进程，发送消息到消息队列
    {
        send_buf.mtype=1;
        strcpy(send_buf.mtext,"My test information");
        printf("发送到消息队列的信息内容为：%s\n",send_buf.mtext);
        if(msgsnd(msqid,&send_buf,20,IPC_NOWAIT)<0)//发送send_buf中的信息到msqid 对应的消息队列
        {
            printf("msgsnd消息发送失败。\n");
            exit(3);
        }
        else
            printf("msgsnd消息发送成功。\n");
        sleep(2);
        exit(0);
    }
    else//子进程，从消息队列中接收消息]
    {
        sleep(2);//等待父进程发送消息完成
        int infolen;//读到的信息数据长度
        if((infolen=msgrcv(msqid,&receive_buf,20,0,IPC_NOWAIT))<0)//自消息队列 接收信息
        {
            printf("msgrcv读取信息错误。\n");
            exit(4);
        }
        else
            printf("msgrcv读取信息成功。\n");
        printf("自消息队列读取到的内容为%s，共读取%d个字节。\n",receive_buf.mtext,infolen);
        if((msgctl(msqid,IPC_RMID,NULL))<0)//删除msqid对应的消息队列
        {
            printf("msgctl函数调用出现错误。\n");
            exit(5);
        }
        else
        {
            printf("识别代号为%d的消息队列已经被成功删除。\n",msqid);
            exit(0);
        }
    }
}
/*********************程序运行结 果*********************
[root@localhost temp]# ./msg
msgget建立消息队列成功，该消息队列识别代号为 98304。
发送到消息队列的信息内容为：My test information
msgsnd消息发送成功。
msgrcv读取信息成功。
自消息队列读取到的内容为My test information，共读取20个字节。
识别代号为98304的消息 队列已经被成功删除。
***********************************************************/

/********************* 程序相关信息*********************
程序编号：013
程序编写起始日期：2008.11.1
程序编写完成日期：2008.11.1
程序修改日 期：                                   修改备注：
程序目的：学习linux共享内存
所用主要函 数：shmget(),shmat(),shmctl(),shmdt()
程序存 疑：
程序完成地点： 宿舍内
*********************程序相关信息*********************/
#include<sys/ipc.h>
#include<sys/shm.h>
#include<stdlib.h>
#include<string.h>
#include<stdio.h>
int main()
{
    int pid,shmid;//后者为共享内存识别代号
    char *write_address;
    char *read_address;
    struct shmid_ds dsbuf;
    if((shmid=shmget(IPC_PRIVATE,32,0))<0)//分配共享内存
    {
        printf("shmid共享内存分配出现错误。\n");
        exit(1);
    }
    else
        printf("shmid共享内存分配成功，共享内存识别代号为：%d。\n",shmid);
    if((pid=fork())<0)
    {
        printf("fork函数调用出现错误！\n");
        exit(2);
    }
    else if(pid>0)//父进程，向共享内存中写入数据
    {
        printf("父进程的ID是：%d\n",getpid());
        write_address=(char *)shmat(shmid,NULL,0);//连接共享内存
        if((int)write_address==-1)
        {
            printf("shmat连接共享内存错误。\n");
            exit(3);
        }
        else
        {
            printf("shmat连接共享内存成功。\n");
            strcpy(write_address,"我是写入共享内存的测试数据");//将数据写入共享内存
            printf("写入共享内存的信息为“%s”。\n",write_address);
            if((shmdt((void *)write_address))<0)//断开与共享内存的连接
                printf("shmdt共享内存断开错误。\n");
            else
                printf("shmdt共享内存断开成功。\n");
            sleep(2);
            return;
        }
    }
    else//子进程，从共享内存中读取数据
    {
        sleep(2);//等待父进程写入共享内存完毕
        printf("子进程ID是：%d\n",getpid());
        if((shmctl(shmid,IPC_STAT,&dsbuf))<0)
        {
            printf("shmctl获取共享内存数据结构出现错误。\n");
            exit(4);
        }
        else
        {
            printf("shmctl获取共享内存数据结构成功。\n建立这个共享内存的进程ID是：%d\n",dsbuf.shm_cpid);
            printf("该共享内存的大小为：%d\n",dsbuf.shm_segsz);
            if((read_address=(char *)shmat(shmid,0,0))<0)//连接共享内存
            {
                printf("shmat连接共享内存出现错误。\n");
                exit(5);
            }
            else
            {
                printf("自共享内存中读取的信息为：“%s”。\n",read_address);
                printf("最后一个操作该共享内存的进程ID是：%d\n",dsbuf.shm_lpid);
                if((shmdt((void *)read_address))<0)//断开与共享内存的连接
                {
                    printf("shmdt共享内存断开错误。\n");
                    exit(6);
                }
                else
                    printf("shmdt共享内存断开成功。\n");
                if(shmctl(shmid,IPC_RMID,NULL)<0)//删除共享内存及其数据结构
                {
                    printf("shmctl删除共享内存及其数据结构出现错误。\n");
                    exit(7);
                }
                else
                    printf("shmctl删除共享内存及其数据结构成功。\n");
                exit(0);
            }
        }    
    }
}
/*********************程序运行结 果*********************
[root@localhost temp]# ./shm
shmid共享内存分配成功，共享内存识别代号 为：1703947。
父进程的ID是：7647
shmat连接共享内存成功。
写入共享内存的信息为“我是写入共享内存的测试数据”。
shmdt 共享内存断开成功。
子进程ID是：7648
shmctl获取共享内存数据结构成功。
建立这个共享内存的进程ID是：7647
该共享内存的大小 为：32
自共享内存中读取的信息为：“我是写入共享内存的测试数据”。
最后一个操作该共享内存的进程ID是：7647
shmdt共享内存断开成功。
shmctl删除共享内存及其数据结构成功。
***********************************************************/

　　 3、示例
　　1)、创建静态库：
　　gcc -c hello.c -o hello.o
ar rcs libhello.a hello.o

　　2)、使用静态库：
　　gcc -o test test.c -static -L. -lhello

　　3)、共享库版本： version.minor.release

4)、构建动态共享库：
　　gcc/g++下加 -fPIC -shared 参数即可
　　其中 -fPIC 作用于编译阶段，告诉编译器产生与位置无关代码(Position-Independent Code)，则产生的代码中，没有绝对地址，全部使用相对地址，故而代码可以被加载器加载到内存的任意位置，都可以正确的执行。这正是共享库所要求的，共 享库被加载时，在内存的位置不是固定的。
　　可以export LD_DEBUG=files，查看每次加载共享库的实际地址。
　　其中 -shared 作用于链接阶段，实际传递给链接器ld，让其添加作为共享库所需要的额外描述信息，去除共享库所不需的信息。
　　可以分解为如 下步骤：
　　I. gcc -c err.c -fPIC -o err.o
　　II. gcc -shared -o liberr.so.0.0 err.o
　　II <==> ld -Bshareable -o liberr.so.0.0 err.o
　　III. ln -s liberr.so.0.0 liberr.so

　　5)、动态共享库的使用：
由共享库加载器自动加载
　　gcc -o test test.c -lerr -L. -Wl,-rpath=./
-Wl,option
　　Pass option as an option to the linker. If option contains commas, it is split into multiple options at the commas.
-rpath: 指定运行时搜索动态库的路径，可以用环境变量LD_LIBRARY_PATH指定。

　　程序自己控制加载、符号解析（使 用libc6之dl库）
　　gcc cos.c -o cos -ldl
　　/* cos.c */
    #include <stdio.h>
    #include <dlfcn.h>
　　int main()
　　{
void *handle;
　　　　double (*cosine)(double);
　　　　char *error;
double rev;

　　　　handle = dlopen("libm.so", RTLD_LAZY); // 加载动态库
if(!handle)
　　　　{
　　　　　　fprintf(stderr, "%s\n", dlerror());
exit(1);
　　　　}

　　　　dlerror();

　　　　cosine = dlsym(handle, "cos"); // 解析符号cos
　　　　if((error = dlerror()) != NULL)
　　　　{
　　　　　　fprintf(stderr, "%s\n", error);
exit(1);
　　　　}

　　　　rev = cosine(3.1415926); // 使用cos函数
　　　　printf("The cos result is: %f\n", rev);

　　　　dlclose(handle);

理解 Proc 文件系统 

--------------------------------------------------------------------------------
 
作者：王旭 翻译 2004-10-05 18:25:55 来自：linuxfocus 
 

目录: 
/proc --- 一个虚拟文件系统 
加载 proc 文件系统 
察看 /proc 的文件 
得到有用的系统/内核信息 
有关运行中的进程的信息 
通过 /proc 与内核交互 
结论 
参考文献

  摘要: 


Linux 内核提供了一种通过 /proc 文件系统，在运行时访问
内核内部数据结构、改变内核设置的机制。尽管在各种硬件
平台上的 Linux 系统的 /proc 文件系统的基本概念都是
相同的，但本文只讨论基于 intel x86 架构的 Linux 
/proc 文件系统。 



_________________ _________________ _________________
 
  
/proc --- 一个虚拟文件系统
/proc 文件系统是一种内核和内核模块用来向进程 (process) 
发送信息的机制 (所以叫做 /proc)。这个伪文件系统让你可以
和内核内部数据结构进行交互，获取 有关进程的有用信息，
在运行中 (on the fly) 改变设置 (通过改变内核参数)。 
与其他文件系统不同，/proc 存在于内存之中而不是硬盘上。
如果你察看文件 /proc/mounts (和 mount 命令一样列出所有
已经加载的文件系统)，你会看到其中 一行是这样的： 



grep proc /proc/mounts
/proc /proc proc rw 0 0

/proc 由内核控制，没有承载 /proc 的设备。因为 /proc 
主要存放由内核控制的状态信息，所以大部分这些信息的
逻辑位置位于内核控制的内存。对 /proc 进行一次 'ls -l'
可以看到大部分文件都是 0 字节大的；不过察看这些文件的
时候，确实可以看到一些信息。这怎么可能？这是因为 /proc
文件系统和其他常规的文件系统一样把自己注册到虚拟文件
系统层 (VFS) 了。然而，直到当 VFS 调用它，请求文件、
目录的 i-node 的时候，/proc 文件系统才根据内核中的信息
建立相应的文件和目录。 

  
加载 proc 文件系统
如果系统中还没有加载 proc 文件系统，可以通过如下命令
加载 proc 文件系统： 


mount -t proc proc /proc 

上述命令将成功加载你的 proc 文件系统。更多细节请阅读
 mount 命令的 man page。 

  
察看 /proc 的文件
/proc 的文件可以用于访问有关内核的状态、计算机的属性、
正在运行的进程的状态等信息。大部分 /proc 中的文件和
目录提供系统物理环境最新的信息。尽管 /proc 中的文件
是虚拟的，但它们仍可以使用任何文件编辑器或像'more', 
'less'或 'cat'这样的程序来查看。当编辑程序试图打开
一个虚拟文件时，这个文件就通过内核中的信息被凭空地 
(on the fly) 创建了。这是一些我从我的系统中得到的
一些有趣结果： 

$ ls -l /proc/cpuinfo
-r--r--r-- 1 root root 0 Dec 25 11:01 /proc/cpuinfo

$ file /proc/cpuinfo
/proc/cpuinfo: empty

$ cat /proc/cpuinfo

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz         : 1000.119
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
sep_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr xmm
bogomips        : 1998.85

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz         : 1000.119
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
sep_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr xmm
bogomips        : 1992.29


这是一个从双 CPU 的系统中得到的结果，上述大部分的信息
十分清楚地给出了这个系统的有用的硬件信息。有些 /proc 
的文件是经过编码的，不同的工具可以被用来解释这些编码
过的信息并输出成可读的形式。这样的工具包括：'top',
 'ps', 'apm' 等。 


  
得到有用的系统/内核信息

proc 文件系统可以被用于收集有用的关于系统和运行中的内
核的信息。下面是一些重要的文件： 

/proc/cpuinfo - CPU 的信息 (型号, 家族, 缓存大小等) 
/proc/meminfo - 物理内存、交换空间等的信息 
/proc/mounts - 已加载的文件系统的列表 
/proc/devices - 可用设备的列表 
/proc/filesystems - 被支持的文件系统 
/proc/modules - 已加载的模块 
/proc/version - 内核版本 
/proc/cmdline - 系统启动时输入的内核命令行参数 
proc 中的文件远不止上面列出的这么多。想要进一步了解
的读者可以对 /proc 的每一个文件都'more'一下或读参考
文献[1]获取更多的有关 /proc 目录中的文件的信息。我
建议使用'more'而不是'cat'，除非你知道这个文件很小，
因为有些文件 (比如 kcore) 可能会非常长。 

  
有关运行中的进程的信息
/proc 文件系统可以用于获取运行中的进程的信息。在 
/proc 中有一些编号的子目录。每个编号的目录对应
一个进程 id (PID)。这样，每一个运行中的进程 /proc 
中都有一个用它的 PID 命名的目录。这些子目录中包含
可以提供有关进程的状态和环境的重要细节信息的文件。
让我们试着查找一个运行中的进程。 

$ ps -aef | grep mozilla
root 32558 32425 8  22:53 pts/1  00:01:23  /usr/bin/mozilla

上述命令显示有一个正在运行的 mozilla 进程的 PID 
是 32558。相对应的，/proc 中应该有一个名叫 32558 的目录


$ ls -l /proc/32558
total 0
-r--r--r--    1 root  root            0 Dec 25 22:59 cmdline
-r--r--r--    1 root  root            0 Dec 25 22:59 cpu
lrwxrwxrwx    1 root  root            0 Dec 25 22:59 cwd -> /proc/
-r--------    1 root  root            0 Dec 25 22:59 environ
lrwxrwxrwx    1 root  root            0 Dec 25 22:59 exe -> /usr/bin/mozilla*
dr-x------    2 root  root            0 Dec 25 22:59 fd/
-r--r--r--    1 root  root            0 Dec 25 22:59 maps
-rw-------    1 root  root            0 Dec 25 22:59 mem
-r--r--r--    1 root  root            0 Dec 25 22:59 mounts
lrwxrwxrwx    1 root  root            0 Dec 25 22:59 root -> //
-r--r--r--    1 root  root            0 Dec 25 22:59 stat
-r--r--r--    1 root  root            0 Dec 25 22:59 statm
-r--r--r--    1 root  root            0 Dec 25 22:59 status

文件 "cmdline" 包含启动进程时调用的命令行。"envir" 进程
的环境变两。 "status" 是进程的状态信息，包括启动进程的
用户的用户ID (UID) 和组ID(GID) ，父进程ID (PPID)，还有
进程当前的状态，比如"Sleelping"和"Running"。每个进程的
目录都有几个符号链接，"cwd"是指向进程当前工作目录的符号
链接，"exe"指向运行的进程的可执行程序，"root"指向被这个
进程看作是根目录的目录 (通常是"/")。目录"fd"包含指向进程
使用的文件描述符的链接。 "cpu"仅在运行 SMP 内核时出现，
里面是按 CPU 划分的进程时间。 

/proc/self 是一个有趣的子目录，它使得程序可以方便地使用 
/proc 查找本进程地信息。/proc/self 是一个链接到 /proc 
中访问 /proc 的进程所对应的 PID 的目录的符号链接。


  
通过 /proc 与内核交互

上面讨论的大部分 /proc 的文件是只读的。而实际上 /proc 
文件系统通过 /proc 中可读写的文件提供了对内核的交互机制。
写这些文件可以改变内核的状态，因而要慎重改动这些文件。
/proc/sys 目录存放所有可读写的文件的目录，可以被用于改变
内核行为。

/proc/sys/kernel - 这个目录包含反通用内核行为的信息。
 /proc/sys/kernel/{domainname, hostname} 存放着机器/网络
的域名和主机名。这些文件可以用于修改这些名字。



$ hostname
machinename.domainname.com

$ cat /proc/sys/kernel/domainname
domainname.com

$ cat /proc/sys/kernel/hostname
machinename

$ echo "new-machinename"  > /proc/sys/kernel/hostname

$ hostname
new-machinename.domainname.com



这样，通过修改 /proc 文件系统中的文件，我们可以修改
主机名。很多其他可配置的文件存在于 /proc/sys/kernel/。
这里不可能列出所有这些文件，读者可以自己去这个目录
查看以得到更多细节信息。
另一个可配置的目录是 /proc/sys/net。这个目录中的文件
可以用于修改机器/网络的网络属性。比如，简单修改一个
文件，你可以在网络上瘾藏匿的计算机。


$ echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all

这将在网络上瘾藏你的机器，因为它不响应 icmp_echo。
主机将不会响应其他主机发出的 ping 查询。

$ ping machinename.domainname.com
no answer from machinename.domainname.com

要改回缺省设置，只要

$ echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all

/proc/sys 下还有许多其它可以用于改变内核属性。读者
可以通过参考文献 [1], [2] 获取更多信息。 

  
结论
/proc 文件系统提供了一个基于文件的 Linux 内部接口。
它可以用于确定系统的各种不同设备和进程的状态。对
他们进行配置。因而，理解和应用有关这个文件系统的
知识是理解你的 Linux 系统的关键。

参考文献
[1] 有关Linux proc 文件系统的文档位于: 
/usr/src/linux/Documentation/filesystems/proc.txt
[2] RedHat Guide: The /proc File System: 
http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/ch-proc.html 

作者：       小徐

QQ:          339534039

转载请注明出处

呵呵，LINUX下历遍目录的方法一般是这样的

打开目录-》读取-》关闭目录

相关函数是

opendir -> readdir -> closedir

#include <dirent.h>

DIR *opendir(const char *dirname);

#include <dirent.h>

struct dirent *readdir(DIR *dirp);

#include <dirent.h>

int closedir(DIR *dirp);

好了，三个函数都出来了呵呵，原型就是上面，给自己解释一下免得以后我自己忘了呵呵！我以经忘过好几回了，所以这次放上博客来

opendir用于打开目录，是类似于流的那种方式，返回一个指向DIR结构体的指针他的参数*dirname是一个字符数组或者字符串常量,

readdir函数用于读取目录，他只有一个参数，这个参数主opendir返回的结构体指针，或者叫句柄更容易理解些吧。这个函数也返回一个结构 体指针 dirent *

dirent的结构如下定义

    struct dirent

    {

        long d_ino;                      /* inode number */

        off_t d_off;                     /* offset to this dirent */

        unsigned short d_reclen;         /* length of this d_name */

        char d_name [NAME_MAX+1];        /* file name (null-terminated) */

    }

结构体中d_ino存放的是该文件的结点数目，什么是结点数目呢我也说不清楚了呵呵，查一下其它资料了

d_off 是文件在目录中的编移，具体是什么意思我也不是很明白，我很少用到它，其本上就是用到d_name short d_reclen是这个文件的长度，需要注意的是这里的长度并不是指文件大小，因为大小和长度是2回事了，你可以用lseek将文件长度移得很长，但大小 其实还是那么大.最后一个元素就是我们要的了，文件名称！

写了一个实例:

/**

* 功能：       Linux下C语言目录历遍 (读取目录)

* 作者：       小徐

* 邮箱：      xjtdy888@163.com

* QQ:          339534039

* 转载请注明出处

*/

#include <stdio.h>

#include <stdlib.h>

#include <sys/types.h>

#include <unistd.h>

#include <dirent.h>

void print_usage(void);

void print_usage(void)

{

printf("Usage: test dirname\n");

}

int main(int argc,char *argv[])

{

DIR * dp;

struct dirent *filename;

if (argc < 2)

{

       print_usage();

       exit(1);

}

dp = opendir(argv[1]);

if (!dp)

{

       fprintf(stderr,"open directory error\n");

       return 0;

}

while (filename=readdir(dp))

{

       printf("filename:%-10s\td_info:%ld\t d_reclen:%us\n",

         filename->d_name,filename->d_ino,filename->d_reclen);

}

closedir(dp);

return 0;

}

将上面代码保存为readdir.c执行下面的命令进行编译测试

[root@phpos ~]# gcc readdir.c

[root@phpos ~]# ./a.out

Usage: test dirname

[root@phpos ~]# ./a.out /etc/samba/

filename:lmhosts             d_info:49296          d_reclen:24s

filename:smb.conf            d_info:49825          d_reclen:24s

filename:smbpasswd           d_info:49402          d_reclen:24s

filename:..                  d_info:47906          d_reclen:16s

filename:secrets.tdb         d_info:49812          d_reclen:24s

filename:.                   d_info:49295          d_reclen:16s

filename:smbusers            d_info:49377          d_reclen:24s

[root@phpos ~]# ./a.out /var/

filename:preserve            d_info:31971          d_reclen:24s

filename:lock                d_info:31966          d_reclen:16s

filename:yp                  d_info:31976          d_reclen:16s

filename:empty               d_info:31962          d_reclen:24s

filename:run                 d_info:31972          d_reclen:16s

filename:lib                 d_info:31939          d_reclen:16s

filename:nis                 d_info:31969          d_reclen:16s

filename:local               d_info:31965          d_reclen:24s

filename:spool               d_info:31973          d_reclen:24s

filename:tmp                 d_info:31941          d_reclen:16s

filename:opt                 d_info:31970          d_reclen:16s

filename:log                 d_info:31959          d_reclen:16s

filename:crash               d_info:31997          d_reclen:24s

filename:..                  d_info:2              d_reclen:16s

filename:account             d_info:32037          d_reclen:24s

filename:mail                d_info:31968          d_reclen:16s

filename:cache               d_info:31960          d_reclen:24s

filename:db                  d_info:31961          d_reclen:16s

filename:.                   d_info:31938          d_reclen:16s

[root@phpos ~]#

转载地址：http://hi.baidu.com/phps/blog/item/92120fd1645fc9d2562c840a.html

首先特别感谢这篇文章给的启发！
http://hi.baidu.com/%D3%EA%BA%E7%D1%F4/blog/item/6490202aaba49193023bf633.html
对原作者表示敬意和膜拜！

fork()之后,非阻塞（异步）等待子进程（回收僵尸）。
fork()之后，子进程和父进程分叉执行，僵尸进程的产生是因为父进程没有给子进程“收尸”造成的，又可以根据危害程度分为下述两类：
总体来说：当子进程结束之后，但父进程未结束之前，子进程将成为僵尸进程。
（1）当子进程结束之后，但父进程未结束之前，子进程将成为僵尸进程，父进程结束后僵尸被init进程回收。
（2）如果子进程结束了，但是父进程始终没有结束，那么这个僵尸将一直存在，而且随着exec，僵尸越来越多。
如下面的代码，在父进程执行的5s内，子进程将为僵尸：

如上面的代码，在父进程的5s内，子进程一直是僵尸！
因此，需要对僵尸进程进行回收，传统的回收方法是，使用wait()函数，等待子进程，wait()是阻塞模式的，当子进程没有结束之前，wait一直等 待，不往下面的语句执行。

转载自：4号程序员

如上面的代码，在子进程执行5秒后，即被回收，在夫进程的20秒内，子进程已经被结束，不再是僵尸。
但是这种利用wait()阻塞等待的方法也有一定的缺陷，那就是父进程必须等待子进程，无法做其他事情，如何非阻塞的等待子进程呢？
man wait,查看NOTES章节，可以找到：
子进程退出的时候，会发送SIGCHLD信号，默认的POSIX不响应，所以，我们只需要把处理SIGCHLD的函数自己实现就OK了，怎么作呢？
signal用于设置处理信号量的规则（或跳转到的函数）

OK，全部代码如下，注意父进程不要再用wait阻塞啦！

SYNOPSIS
       #include <unistd.h>

       int brk(void *end_data_segment);

       void *sbrk(intptr_t increment);

DESCRIPTION
       brk()  sets the end of the data segment to the value specified by end_data_segment,
       when that value is reasonable, the system does have enough memory and  the  process
       does not exceed its max data size (see setrlimit(2)).

       sbrk() increments the program's data space by increment bytes.  sbrk() isn't a sys-
       tem call, it is just a C library wrapper.  Calling sbrk() with an  increment  of  0
       can be used to find the current location of the program break.

RETURN VALUE
       On  success,  brk()  returns zero, and sbrk() returns a pointer to the start of the
       new area.  On error, -1 is returned, and errno is set to ENOMEM.

CONFORMING TO
       4.3BSD

       brk() and sbrk() are not defined in the C Standard and  are  deliberately  excluded
       from the POSIX.1 standard (see paragraphs B.1.1.1.3 and B.8.3.3).

NOTES
       Various  systems  use  various  types for the parameter of sbrk().  Common are int,
       ssize_t, ptrdiff_t, intptr_t.  XPGv6 obsoletes this function.

SEE ALSO
       execve(2), getrlimit(2), malloc(3)

    The brk() and sbrk() functions are used to change the amount of memory
    allocated in a process's data segment. They do this by moving the loca-
    tion of the ``break''. The break is the first address after the end of  
    the process's uninitialized data segment (also known as the ``BSS'').


brk and sbrk设置的是BSS里的边界，具体什么是BSS呢
bss = "Block Started by Symbol" (由符号启始的区块）

Dennis Ritchie 曾说过：
这个缩写也许有其它说法，但事实上我们采用这个缩写的本意是
"Block Started by Symbol"。它是 FAP 上的伪指令，FAP
(Fortran Assembly [-er?] Program) 是指 IBM 704-709-7090-7094
这种机型的组译器。这个指令可定义自己的标号，并且预留一定数目
的字组空间。还有另一个伪指令 BES，是 "Block Ended by
Symbol"，跟 BSS 指令几乎一样，不同点在于标号是定义在预留字组
空间尾端的地址 + 1 的地方。在这些机器上，Fortran 的数组是以反
方向储存，而且数组的索引是从 1 算起。

这种用法是合理的，因为这跟 UNIX 上标准的程序加载器一样，程序
码当中并非真的放入这一整块预留空间，而是先用一个数目表示，在
加载时才真的把所需的预留空间定出来。
from：
Linux man page and
http://www.linuxforum.net/forum/gshowflat.php?Cat=&Board=linuxK&Number=300677&page=16&view=collapsed&sb=5&o=all&fpart=

用strace调试程序

     在理想世界里，每当一个程序不能正常执行一个功能时，它就会给出一个有用的错误提示，告诉你在足够的改正错误的线索。但遗憾的是，我们不是生活在理想世界里，起码不总是生活在理想世界里。有时候一个程序出现了问题，你无法找到原因。

这就是调试程序出现的原因。strace是一个必不可少的调试工具，strace用来监视系统调用。你不仅可以调试一个新开始的程序，也可以调试一个已经在运行的程序（把strace绑定到一个已有的PID上面）。

首先让我们看一个真实的例子：

[BOLD]启动KDE时出现问题[/BOLD]

前一段时间，我在启动KDE的时候出了问题，KDE的错误信息无法给我任何有帮助的线索。

代码：


_KDE_IceTransSocketCreateListener: failed to bind listener _KDE_IceTransSocketUNIXCreateListener: ...SocketCreateListener() failed _KDE_IceTransMakeAllCOTSServerListeners: failed to create listener for local Cannot establish any listening sockets DCOPServer self-test failed.



对我来说这个错误信息没有太多意义，只是一个对KDE来说至关重要的负责进程间通信的程序无法启动。我还可以知道这个错误和ICE协议（Inter Client Exchange）有关，除此之外，我不知道什么是KDE启动出错的原因。

我决定采用strace看一下在启动dcopserver时到底程序做了什么：

代码：


strace -f -F -o ~/dcop-strace.txt dcopserver



这里 -f -F选项告诉strace同时跟踪fork和vfork出来的进程，-o选项把所有strace输出写到~/dcop-strace.txt里面，dcopserver是要启动和调试的程序。

再次出现错误之后，我检查了错误输出文件dcop-strace.txt，文件里有很多系统调用的记录。在程序运行出错前的有关记录如下：

代码：


27207 mkdir("/tmp/.ICE-unix", 0777) = -1 EEXIST (File exists) 27207 lstat64("/tmp/.ICE-unix", {st_mode=S_IFDIR|S_ISVTX|0755, st_size=4096, ...}) = 0 27207 unlink("/tmp/.ICE-unix/dcop27207-1066844596") = -1 ENOENT (No such file or directory) 27207 bind(3, {sin_family=AF_UNIX, path="/tmp/.ICE-unix/dcop27207-1066844596"}, 38) = -1 EACCES (Permission denied) 27207 write(2, "_KDE_IceTrans", 13) = 13 27207 write(2, "SocketCreateListener: failed to "..., 46) = 46 27207 close(3) = 0 27207 write(2, "_KDE_IceTrans", 13) = 13 27207 write(2, "SocketUNIXCreateListener: ...Soc"..., 59) = 59 27207 umask(0) = 0 27207 write(2, "_KDE_IceTrans", 13) = 13 27207 write(2, "MakeAllCOTSServerListeners: fail"..., 64) = 64 27207 write(2, "Cannot establish any listening s"..., 39) = 39



其 中第一行显示程序试图创建/tmp/.ICE-unix目录，权限为0777，这个操作因为目录已经存在而失败了。第二个系统调用（lstat64）检查 了目录状态，并显示这个目录的权限是0755，这里出现了第一个程序运行错误的线索：程序试图创建属性为0777的目录，但是已经存在了一个属性为 0755的目录。第三个系统调用（unlink）试图删除一个文件，但是这个文件并不存在。这并不奇怪，因为这个操作只是试图删掉可能存在的老文件。

但 是，第四行确认了错误所在。他试图绑定到/tmp/.ICE-unix/dcop27207-1066844596，但是出现了拒绝访问错误。. ICE_unix目录的用户和组都是root，并且只有所有者具有写权限。一个非root用户无法在这个目录下面建立文件，如果把目录属性改成0777， 则前面的操作有可能可以执行，而这正是第一步错误出现时进行过的操作。

所以我运行了chmod 0777 /tmp/.ICE-unix之后KDE就可以正常启动了，问题解决了，用strace进行跟踪调试只需要花很短的几分钟时间跟踪程序运行，然后检查并分析输出文件。

说 明：运行chmod 0777只是一个测试，一般不要把一个目录设置成所有用户可读写，同时不设置粘滞位(sticky bit)。给目录设置粘滞位可以阻止一个用户随意删除可写目录下面其他人的文件。一般你会发现/tmp目录因为这个原因设置了粘滞位。KDE可以正常启动 之后，运行chmod +t /tmp/.ICE-unix给.ICE_unix设置粘滞位。

[BOLD]解决库依赖问题[/BOLD]

starce 的另一个用处是解决和动态库相关的问题。当对一个可执行文件运行ldd时，它会告诉你程序使用的动态库和找到动态库的位置。但是如果你正在使用一个比较老 的glibc版本（2.2或更早），你可能会有一个有bug的ldd程序，它可能会报告在一个目录下发现一个动态库，但是真正运行程序时动态连接程序 （/lib/ld-linux.so.2）却可能到另外一个目录去找动态连接库。这通常因为/etc/ld.so.conf和 /etc/ld.so.cache文件不一致，或者/etc/ld.so.cache被破坏。在glibc 2.3.2版本上这个错误不会出现，可能ld-linux的这个bug已经被解决了。

尽管这样，ldd并不能把所有程序依赖的动态库列出 来，系统调用dlopen可以在需要的时候自动调入需要的动态库，而这些库可能不会被ldd列出来。作为glibc的一部分的NSS（Name Server Switch）库就是一个典型的例子，NSS的一个作用就是告诉应用程序到哪里去寻找系统帐号数据库。应用程序不会直接连接到NSS库，glibc则会通 过dlopen自动调入NSS库。如果这样的库偶然丢失，你不会被告知存在库依赖问题，但这样的程序就无法通过用户名解析得到用户ID了。让我们看一个例 子：

whoami程序会给出你自己的用户名，这个程序在一些需要知道运行程序的真正用户的脚本程序里面非常有用，whoami的一个示例输出如下：
代码：


# whoami root



假设因为某种原因在升级glibc的过程中负责用户名和用户ID转换的库NSS丢失，我们可以通过把nss库改名来模拟这个环境：
代码：


# mv /lib/libnss_files.so.2 /lib/libnss_files.so.2.backup # whoami whoami: cannot find username for UID 0



这里你可以看到，运行whoami时出现了错误，ldd程序的输出不会提供有用的帮助：
代码：


# ldd /usr/bin/whoami libc.so.6 => /lib/libc.so.6 (0x4001f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)



你只会看到whoami依赖Libc.so.6和ld-linux.so.2，它没有给出运行whoami所必须的其他库。这里时用strace跟踪whoami时的输出：
代码：


strace -o whoami-strace.txt whoami open("/lib/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) open("/lib/i686/mmx/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/i686/mmx", 0xbffff190) = -1 ENOENT (No such file or directory) open("/lib/i686/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/i686", 0xbffff190) = -1 ENOENT (No such file or directory) open("/lib/mmx/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib/mmx", 0xbffff190) = -1 ENOENT (No such file or directory) open("/lib/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/lib", {st_mode=S_IFDIR|0755, st_size=2352, ...}) = 0 open("/usr/lib/i686/mmx/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) stat64("/usr/lib/i686/mmx", 0xbffff190) = -1 ENOENT (No such file or directory) open("/usr/lib/i686/libnss_files.so.2", O_RDONLY) = -1 ENOENT (No such file or directory)



你可以发现在不同目录下面查找libnss.so.2的尝试，但是都失败了。如果没有strace这样的工具，很难发现这个错误是由于缺少动态库造成的。现在只需要找到libnss.so.2并把它放回到正确的位置就可以了。

[BOLD]限制strace只跟踪特定的系统调用[/BOLD]

如果你已经知道你要找什么，你可以让strace只跟踪一些类型的系统调用。例如，你需要看看在configure脚本里面执行的程序，你需要监视的系统调用就是execve。让strace只记录execve的调用用这个命令：

代码：


strace -f -o configure-strace.txt -e execve ./configure



部分输出结果为：
代码：


2720 execve("/usr/bin/expr", ["expr", "a", ":", "(a)"], [/* 31 vars */]) = 0 2725 execve("/bin/basename", ["basename", "./configure"], [/* 31 vars */]) = 0 2726 execve("/bin/chmod", ["chmod", "+x", "conftest.sh"], [/* 31 vars */]) = 0 2729 execve("/bin/rm", ["rm", "-f", "conftest.sh"], [/* 31 vars */]) = 0 2731 execve("/usr/bin/expr", ["expr", "99", "+", "1"], [/* 31 vars */]) = 0 2736 execve("/bin/ln", ["ln", "-s", "conf2693.file", "conf2693"], [/* 31 vars */]) = 0



你 已经看到了，strace不仅可以被程序员使用，普通系统管理员和用户也可以使用strace来调试系统错误。必须承认，strace的输出不总是容易理 解，但是很多输出对大多数人来说是不重要的。你会慢慢学会从大量输出中找到你可能需要的信息，像权限错误，文件未找到之类的，那时strace就会成为一 个有力的工具了。
from:
http://blog.chinaunix.net/u1/55468/showart_2003061.html

昨天解决了一个隐蔽的内存泄漏问题，原因是pthread_create后的僵死线程没有释放导致的内存持续增长。
现象是这样的：短时间内程序运行正常，但跑了12小时左右，用top查看其内存占用居然高达2G，于是马上意识到有内存泄漏。

最先想到的是malloc/free、new/delete没有配对，申请的内存没有释放。于是写了个跟踪malloc/free调用的模块，不过检查中并没有找到未释放的内存。之后怀疑是不是 free then malloc 导致的内存管理错误（事实证明虽然free后不是立即回收内存，但是接连调用free & malloc并不会影响操作系统的内存管理），不过写了个小程序发现并不是这么回事。

陷入窘境了，只好用最小系统法把功能部分和内存分配都给屏蔽掉，这时发现内存泄漏依然存在！仔细看top的输出，几乎是每次创建线程时内存就往上涨一点，只是增长速度不是很快，看来是线程的问题了。仔细分析发现，之前图简单 pthread_create (&thread, NULL, &thread_function, NULL); 就这么写了，参数2没有设置线程结束后自动detach，并且没有使用pthread_join或pthread_detach释放执行结束后线程的空间！

Linux man page 里有已经说明了这个问题：
    When a joinable thread terminates, its memory resources (thread descriptor and stack) are not deallocated until another thread performs pthread_join on it. Therefore, pthread_join must be called  once  for each joinable thread created to avoid memory leaks.

也就说线程执行完后如果不join的话，线程的资源会一直得不到释放而导致内存泄漏！一时的图快后患无穷啊。

解决办法：

代码

 1 // 最简单的办法，在线程执行结束后调用pthread_detach让他自己释放
 2 pthread_detach(pthread_self());
 3 
 4 
 5 // 或者创建线程前设置 PTHREAD_CREATE_DETACHED 属性
 6 pthread_attr_t attr;
 7 pthread_t thread;
 8 pthread_attr_init (&attr);
 9 pthread_attr_setdetachstate (&attr, PTHREAD_CREATE_DETACHED);
10 pthread_create (&thread, &attr, &thread_function, NULL);
11 pthread_attr_destroy (&attr);

第2行的那种方法最简单，在线程函数尾部加上这句话就可以将线程所占用的资源给释放掉；或者像 5-11 所示的方法设置detach属性，这样也会在线程return/pthread_exit后释放内存。

其实仔细想想，valgrind检查时已经提示了pthread_create没有释放的问题，只是之前没引起注意。其实这样的问题也只有在长时间运行时，慢慢积累这一点点的内存才会暴露出来，看来valgrind的提示也不能置之不理啊。

from：

http://www.cnblogs.com/bits/archive/2009/12/04/no_join_or_detach_memory_leak.html

进程是一个动态的实体，所以他是有生命的。从创建到消亡，是一个进程的整个生命周期。在这个周期中，进程可能会经历各种不同的状态。一般来说，所有进程都要经历以下的3个状态：

1. 就绪态。指进程已经获得所有所需的其他资源，正在申请处理处理器资源，准备开始执行。这种情况下，称进程处于就绪态。
2. 阻塞态。指进程因为需要等待所需资源而放弃处理器，或者进程本不拥有处理器，且其他资源也没有满足，从而即使得到处理器也不能开始运行。这种情况下，进程处于阻塞态。阻塞状态也称休眠状态或者等待状态。
3. 运行态。进程得到了处理器，并不需要等待其他任何资源，正在执行的状态，称之为运行态。只有在运行态时，进程才可以使用所申请到的资源。

在Linux系统中，将各种状态进行了重新组织，由此得到了Linux进程的几个状态：

• RUNNING：正在运行或者在就绪队列中等待运行的进程。也就是上面提到的运行态和就绪态进程的综合。一个进程处于RUNNING状态，并不代表他一定在被执行。由于在多任务系统中，各个就绪进程需要并发执行，所以在某个特定时刻，这些处于RUNNING状态的进程之中，只有一个能得到处理器，而其他进程必须在一个就绪队列中等待。即使是在多处理器的系统中，Linux也只能同时让一个处理器执行任务。
• UNINTERRUPTABLE:不可中断阻塞状态。处于这种状态的进程正在等待队列中，当资源有效时，可由操作系统进行唤醒，否则，将一直处于等待状态。
• INTERRUPTABLE：可中断阻塞状态。与不可中断阻塞状态一样，处于这种状态的进程在等待队列中，当资源有效时，可以有操作系统进行唤醒。与不可中断阻塞状态有所区别的是，处于此状态中的进程亦可被其他进程的信号唤醒。
• STOPPED：挂起状态。进程被暂停，需要通过其它进程的信号才能被唤醒。导致这种状态的原因有两种。其一是受到相关信号(SIGSTOP,SIGSTP,SIGTTIN或SIGTTOU)的反应。其二是受到父进程ptrace调用的控制，而暂时将处理器交给控制进程。
• ZOMBIE：僵尸状态。表示进程结束但尚未消亡的一种状态。此时进程已经结束运行并释放掉大部分资源，但尚未释放进程控制块。