加强linux c/c++ 多线程程序的稳定

要想使写出的代码稳定可靠，以下是几个措施:

一.确保线程安全

要做到下面两点
1.使用可重入的函数 reentrant ：即可以在任意时刻被中断， 稍后再继续运行，不会丢失数据的函数。即此类函数中不使用能被其他线程改写的变量.
2.在使用全局变量时保护自己的数据即进行同步：比如加锁或者进行原子操作。

二.使用队列

把多个线程可能需要写的动作放在一个队列里面，统一由一个线程去排队执行。队列需要加锁。

在不止一个线程中对vector等数据结构操作时，必须加锁。否则出现莫名其妙的错误，比如内存double delete，空指针等。
{
Lock lock(&m_mutex);
m_vctUpDataM.push_back(upData);
}

三.
使用线程安全的库函数
使用
捕获异常和
检查函数返回值

使用某些库函数时，需要检查参数：比如atoi(p),如果p==NULL,aoti会导致程序崩溃。

四.使用设计模式

几个函数组成的程序，不需要搭建框架。但是如果一个比较复杂的程序仍然按照自己的意愿去写，就有可能工作的不太稳定。
参考后面系列模式文档：

主要参考书籍：

大化设计模式
面向模式的软件架构1
面向模式的软件架构2
面向模式的软件架构2
head first
设计模式 GOF
软件架构设计 温昱
程序员必读软件架构 simon brown
人月神话
人件
设计原本
软件产品架构师手记

而C++在嵌入式上更加脆弱

（个人认为是嵌入式的编译器一般版本比较旧，对c++的新特性支持具有不确定的bug）
之前用C++在mx53+linux2.6.35上做过一个项目，经过辛苦调试，稳定性还可以。当时用到c++的面向对象和STL。
现在另外一个项目，引入boost库到系统中，感觉系统不太稳定，经常会segmentation fault，感觉程序不可控。
不清楚是因为mx53的编译器对复杂的boost编译有问题，还是其他问题，有点不敢用了。

看来，在嵌入式设备linux中，最好直接用c写。如果要用到c++，使用c++的最少特性最好，std的map也最好别用。其他大型的复杂库，最好别用。稳定性最重要。

复现 segmentation fault

报错Segmentation fault
空指针：
char buf[8]={0};
FILE *fp ;
int len = fwrite(  buf, 1, sizeof(buf), fp);
return 0;

char buf[8]={0};
FILE *fp ;
fclose(fp);
return 0;

char *p;
*p=9;
return 0;

char *p;
int i = atoi(p);
return 0;



#define LENG  ( 1024*1024*7 + 1024*1021 + 256)
char buf[LENG]={0};
memset(buf,0x61,sizeof(buf));
printf("%c\n",buf[LENG-1]);

return 0;

当分配不到足够的空间时，也会
Segmentation fault

在imx53 linux 2.6.35  512MB上，应用程序最多可以申请局部变量(栈内存)接近8MB


#define LENG  ( 1024*1024*450)
char *p = new char [LENG];


memset(p,0x61,LENG);
printf("%c\n",p[LENG-1]);
return 0;
在imx53 linux 2.6.35  512MB上，应用程序可以动态申请内存450MB,
而申请512MB时，系统报错
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted

造成segmentation fault的可能原因分析

1.内存访问越界

 a) 由于使用错误的下标，导致数组访问越界

 b) 搜索字符串时，依靠字符串结束符来判断字符串是否结束，但是字符串没有正常的使用结束符

 c) 使用strcpy, strcat, sprintf, strcmp, strcasecmp等字符串操作函数，将目标字符串读/写爆。应该使用strncpy, strlcpy, strncat, strlcat, snprintf, strncmp, strncasecmp等函数防止读写越界。

2 多线程程序使用了线程不安全的函数。

3 多线程读写的数据未加锁保护。对于会被多个线程同时访问的全局数据，应该注意加锁保护，否则很容易造成core dump

4 非法指针

a) 使用空指针

b) 随意使用指针转换。一个指向一段内存的指针，除非确定这段内存原先就分配为某种结构或类型，或者这种结构或类型的数组，否则不要将它转换为这种结构或类型的指针，而应该将这段内存拷贝到一个这种结构或类型中，再访问这个结构或类型。这是因为如果这段内存的开始地址不是按照这种结构或类型对齐的，那么访问它时就很容易因为bus error而core dump.

5 堆栈溢出.不要使用大的局部变量（因为局部变量都分配在栈上），这样容易造成堆栈溢出，破坏系统的栈和堆结构，导致出现莫名其妙的错误。

调试方法：

Linux下的段错误(Segmentation fault)产生的原因及调试..._百度文库

Linux下的段错误（Segmentation fault）产生的原因及调试方法（经典）
2009-04-05 11:25
        简而言之,产生段错误就是访问了错误的内存段，一般是你没有权限，或者根本就不存在对应的物理内存,尤其常见的是访问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)中出错的,信息已然不是很完整,不过有总比没有好的啊!
后记:
本文给出了分析"段错误"的几种方法,不要认为这是与孔乙己先生的"回"字四种写法一样的哦,因为每种方法都有其自身的适用范围和适用环境,请酌情使用,或遵医嘱。







1.