Glibc中std::qsort在多线程下出core原因分析及解决

1、问题：

一个C实现的32位多线程服务在启动时core dump. 该服务运行了一年多，而此问题仅出现了一次，是一个比较难复现的问题。 出core的位置

在C库的qsort函数，信号是signal 8(算术错).

2、定位：

core的栈的结构如下:

#0 0x4202a801 in qsort () from /lib/i686/libc.so.6
#1 0x0804e74e in getFRes (databuf=0x406697fc) at fs.cpp:128
#2 0x0804ea74 in adjustOrder (databuf=0x406697fc) at fs.cpp:233
#3 0x0804e553 in Search (databuf=0x406697fc) at fs.cpp:66
#4 0x0804e4b8 in getBResponse (databuf=0x406697fc) at fs.cpp:29
#5 0x0804c559 in getResponse (databuf=0x406697fc) at fs.cpp:283
#6 0x0804c292 in thread_main (arg=0x1) at fs.cpp:222
#7 0x40020941 in pthread_start_thread () from /lib/i686/libpthread.so.0

可以先通过GDB的命令查看出core的汇编指令。当程序core时，$eip保存了当时程序运行指令地址。通过x /i 命令可以将内存以汇编指令的

方式查看。 这样就可以得到core dump时运行的汇编指令。如下：

(gdb) x /i $eip
0x4202a801 < qsort+65>: divl 0x724(%ebx)

按汇编看，应该是除法指令出问题，一般觉得会是除数为0之类的错误 由于glibc是开源的，可以查看一下qsort原代码，此处要注意版本问题，要下相同的版本才能方便问题定位。不同linux发行版带的glibc的版本可能是不同的，而且系统维护人员也可能升级过相关的库。 通过以下几个命令可以查看系统的glibc版本。

$ ldd ./bin/fras libpthread.so.0 =>/lib/i686/libpthread.so.0 (0x4001a000)

libcrypto.so.2 =>/lib/libcrypto.so.2 (0x4004b000) libc.so.6 =>/lib/i686/libc.so.6 (0x42000000)
libdl.so.2 =>/lib/libdl.so.2 (0x4011f000)/lib/ld-linux.so.2 =>/lib/ld-linux.so.2 (0x40000000)
/lib/i686/libc.so.6 (0x42000000) libdl.so.2 =>/lib/libdl.so.2 (0x4011f000) /lib/ld-linux.so.2 =>/lib/ld-linux.so.2 (0x40000000)

$ /lib/i686/libc.so.6 -v 

GNU C Library development release version 2.2.93 , by Roland McGrath et al. Copyright (C)1992-2001, 2002

Free Software Foundation, Inc. This is free software; see the sourcefor copying conditions. There is NO warranty; not even for

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2 20020903(Red Hat Linux 8.03.2-7)

. Compiled on a Linux 2.4.9-9 system on 2002-09-05. Available extensions:

下载glibc 2.2.93版本，查看其qsort实现，以下为简化版的原代码

void qsort (void*b, size_t n, size_t s, __compar_fn_t cmp)
{
    const size_t size = n * s;
    if(size < 1024)
    {
        void*buf = __alloca (size);
        /* The temporary array is small, so put it on the stack. */
        msort_with_tmp (b, n, s, cmp, buf);
    }
    else
    {
        staticlong int phys_pages;
        static int pagesize;
        if(phys_pages ==0)
        {
            phys_pages = __sysconf (_SC_PHYS_PAGES);

            if(phys_pages ==-1)
                phys_pages = (longint)(~0ul >>1);
            phys_pages /=4;
            pagesize = __sysconf (_SC_PAGESIZE);
        }
        if(size / pagesize > phys_pages)
            _quicksort (b, n, s, cmp);
        ......

    }
}

根据错误类型（除法错），可以看到出问题的指令刚好对应代码中(size / pagesize > phys_pages)部分; 看else部分，有两个static变量如下

static long int phys_pages;
static int pagesize;

在多线程情况下，线程A先运行到phys_pages = __sysconf (_SC_PHYS_PAGES)处，静态变量 phys_pages 的值将被修改，即不为0，而pagesize未被赋值. 若此时发生线程切换，线程B开始运行，到分支判断处phys_pages已不为0，所以else条件将被执行，而此时phys_pages值为非0，且pagesize尚未被赋 值，结果 (size / pagesize)这一步就发生除0错误了。所以，core dump时的表现就是signal 8即算术错。

3、解决：

可见，该glibc版本的qsort函数不是多线程安全的。 在不修改glibc的基础上，可以考虑绕过此问题的办法：

在主程序（线程未启动时）中先调用qsort一次，为static变量赋上值。
需要注意的：初始化时，n*s必须大于1024，否则pagesize没进行初始化。

4、补充

qsort的比较函数在元素相等情况下，没有返回0值，导致程序出core，例如

int compare_ps_term(const void* p1, const void* p2){        
        if (NULL == p1 || NULL == p2) {
                return -1; 
       }
       seg_info_t* term1 = (seg_info_t*)(p1);
       seg_info_t* term2 = (seg_info_t*)(p2);        
       try {
                if (term1->weight < term2->weight) 
                 {               
                       return 1;
                 } else {
                        return -1;
                }
        } catch (...) {
                WARNING_LOG("throw exception fail to cmp ps_term weight!)");
                return -1;        
        }
}

解决方法：

qsort的排序函数，一定要返回-1，0，1这三个值

5、引申

glibc的qsort源码阅读笔记