上月，喻信星空BBS出现了一次重大的故障，管理员在改变某版面属性操作后，term界面挂起，之后账号信息等数据丢失。分析良久，均未找到具体原因。而此站在08年底迁移到新主机上时，并未更改过程序，其二进制代码甚至都没有重新编译就可以直接使用，而此次使用的功能以往也表现正常，此番故障匪夷所思。
    在喻信测试站上，我重复了一遍管理员的操作，证实故障可重现，于是通过gdb编译定位了故障代码，结论却令我惊讶。故障点位于fileio.c这一BBS底层自封装库当中，函数rm_dir用于递归删除某一目录及其下所有的文件，部分代码如下：
static int rm_dir(char *fpath)
{
        DIR    *dirp;
        struct dirent *de;
        char    buf[256], *fname;
        if (!(dirp = opendir(fpath)))
                return -1;

        readdir(dirp);
        readdir(dirp);

        while (de = readdir(dirp)) {
                fpath = de->d_name;
                ……
        }
        ……
}
    此函数通过使用系统库函数opendir和readdir打开目录并读取目录下的每一项，若该项是目录，则递归调用rm_dir，若是文件，使用unlink删除文件内容。具体实现上，在使用opendir之后，连续调用两次readdir以避开"."和".."两个目录项，接着处理之后的每一项。此次故障调试时却发现，这个处理策略并未避开"."和".."两个目录项，导致删除时越过了本级回到上一级目录去删除了。可以前函数的表现应该是正常的呀，不管是在Linux环境还是Solaris环境都是如此，01年我在调试此函数时还顺带解决过在ucb库里的错位问题，所以印象深刻。可为什么此番会出现重大的误删除问题呢？
    对比喻信星空BBS在换机器前后的环境，之前用glibc-2.3.2，更换之后采取glibc-2.5，莫非底层库函数出了问题？于是写了一个简单的测试程序，用于输出readdir顺序读出的结果。测试结果显示，在glibc-2.3.5的环境下，一个目录的头两个readdir输出是"."和".."，Solaris 9下也为此。而glibc-2.5、glibc-2.6以及我刚刚升级到的glibc-2.10.1均为乱序输出，"."和".."并不一定都是在头两个输出。之前的代码，估计是顾及到执行效率，兼考虑到libc在实现时将"."和".."放在头两个输出，为减少strcmp的调用，opendir之后直接放过两个readdir，接着“放心大胆”的进行处理。然而，一旦libc底层库的实现发生改变，输出并非"."和".."打头时，这段代码就越界闯出大祸。修正的部分不得不重新加上"."和".."的strcmp判别。
    虽然这部分的代码并不是我所写，但对此部分检视时虽有顾虑却并没有放在心上。在此不由得感慨以前总听着说“编程技巧不要依赖于编译器、库函数的内部实现，否则容易出问题”，并没有深刻体会，这次活生生的碰到一个例子，也赔上几天的数据恢复工作代价。

ps: 白云黄鹤BBS的代码当中也有这个问题，目前的系统工作正常，但若更新系统，一定要注意先修复这个bug。

    上个月的一篇博文《glibc-2.10.1头文件string.h带来的问题》提到在更新了glibc之后，不少地方编译都会出现问题。这一现象在我以前升级glibc-2.3.5的时候也遇见不少。再次碰到以后思忖良久，觉得还是应该再次编译gcc尝试一把。我的系统是首先在glibc-2.3.5环境下升级到gcc-4.4.0的，之后在gcc-4.4.0和glibc-2.3.5的环境下编译了glibc-2.10.1，并成功升级，但并未再次编译gcc-4.4.0。于是再次在gcc-4.4.0和glibc-2.10.1环境下重新编译gcc-4.4.0，update之后换回原版的string.h，再未出现类似的编译问题。
    感觉glibc和gcc两者就像一个连环套，真是奇妙啊。
    ps：gcc-4.4.0在支持C/C++的编译需求下需要1.2G的空间才能完成编译工作，比kernel还要大，并且编译时间长达两小时。

2009年7月22日 星期三

    今日在新系统当中编译bison时提示有编译错误：
/usr/include/string.h:546: error: expected declaration specifiers or ‘…’ before ‘__locale_t’
/usr/include/string.h:547: error: nonnull argument with out-of-range operand number (argument 1, operand 3)
/usr/include/string.h:550: error: expected declaration specifiers or ‘…’ before ‘__locale_t’
/usr/include/string.h:551: error: nonnull argument with out-of-range operand number (argument 1, operand 4)

    由于新系统刚刚使用了glibc-2.10.1，其中的头文件也是glibc编译以后替换的，于是怀疑glibc库的头文件出现了问题。当然为了排除gcc的错误，在当前环境下重新编译gcc，同样无法通过。遂构造一个简单的.c文件进行编译：
#include <stdio.h>
#include <string.h>

int main(void)
{
        printf("hello\n");
        return 0;
}

    用gcc test.c编译正常，回头查找string.h当中提示错误的地方，发现如果define了__USE_GNU，则编译出错。而bison的源码当中用了define _GNU_SOURCE，同样造成了__USE_GNU的定义。于是用gcc -D_GNU_SOURCE test.c，错误重现。
    查找string.h的错误部分：
extern int strcasecmp_l (__const char *__s1, __const char *__s2,
                        __locale_t __loc)
     __THROW __attribute_pure__ __nonnull ((1, 2, 3));

extern int strncasecmp_l (__const char *__s1, __const char *__s2,
                          size_t __n, __locale_t __loc)
     __THROW __attribute_pure__ __nonnull ((1, 2, 4));

    属性的设置并无问题，怀疑__locale_t没有定义。在/usr/include下查找__locale_t的定义，出现在xlocale.h当中，同时发现在stdlib.h当中已有相关的include。于是尝试将test.c改为：
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void)
{
        printf("hello\n");
        return 0;
}
    编译无错。于是对比另外一个系统的string.h与当前的string.h的区别，发现在以上两个函数的声明前有一句#include <xlocale.h>，而glibc-2.10.1的string.h头文件内并无这一句。于是加上，测试以后一切ok。
   不知道这个地方是怎么遗漏了。google查到的很多页面都没有具体的解决方案，哪位朋友遇到这样的问题参考一下上面的办法吧。

    以往使用信号量的情形通常都是用于进程间互斥，锁定临界区。以前在维护bbs的代码过程当中，学会了用文件锁flock，后来拜读APUE学会了信号量，信号量还是比文件锁有优势的，效率不是高那么一点，起码不用打开文件关闭文件这些耗时间的工作。但是信号量最大的一个问题就是一旦锁定，若在解锁之前出现程序崩溃等segment fault问题，将直接导致锁定的信号量无法恢复，形成永久占用。文件锁则没有这个问题，进程的退出将导致文件描述符关闭，在该描述符上进行的锁定操作就自行解除了。
    好在设计信号量的前辈们考虑到了这个因素，在加锁的时候会有一个UNDO的设置，也就是在调用semop的时候指定操作结构体当中可以放置一个UNDO参数，我通常都是这样去调用的：
semop(iSemID, &stLocksem, 1);
    其中stLocksem就是定义的一个操作结构体，一般定义为：
static struct sembuf stLocksem={0, -1, SEM_UNDO}, stUnlocksem={0, 1, SEM_UNDO};
    这样的UNDO选项会让内核记录一个与调用进程相关的UNDO记录，如果该进程崩溃，则根据这个进程的UNDO记录自动恢复相应信号量的计数值。详细的可以参考man pages。

    今天想要记录的内容不是来谈这个锁定的。前面也提到了，信号量通常用于锁定临界区，但还有一个重要的工作，也是信号量常干的活——同步进程（线程）。以往我自己写的程序，比较少涉及这方面的工作，最近演了这么一出，在这个信号量锁定上就“老革命碰到新问题了”。
    程序刚开始运行时，挺好。若干次同步后，程序报锁定失败，semop返回-1，errno返回值ERANGE(34)，就是number out of range。在每次锁定解锁之前都用semctl检查信号量的值，始终保持0/1的范围，很正常。百思不得其解之间，把眼光盯向了SEM_UNDO，琢磨良久，才估计可能是由于UNDO造成的，试着把前述结构体当中的SEM_UNDO去掉，一切又都ok了。

    原来对于SEM_UNDO来说，内核记录的信息是跟进程相关的。一个进程在lock的时候设置一个UNDO，那么对应该进程的UNDO计数就多一个，unlock的时候设置一个UNDO，那么计数就减一个。对于临界区互斥的应用而言，lock和unlock都是在一个进程当中完成，于是UNDO可以切实发挥作用。然而，用在同步进程（线程）里，由于是生产者-消费者模型，一边不停的lock，另一边不停的unlock，那么使用UNDO就不起作用了，而且由于都是单边操作，导致UNDO计数对单一进程而言，只朝一个方向发展，最后必定是超过内核限制值，当然出现了ERANGE的错误。
    接着，为了验证这个问题，单独写了一对小程序加解锁并显示锁定次数值。果然在次数达到32768时候，出现ERANGE错误，证实此事。

    最近团队里面新增了一个ADSL出口，于是拖来一台旧电脑作网关出去。因为想直接用已经很成熟的RAM Disk小系统，但是又要考虑网关配置经常改动的情况，于是在小系统当中添加了一个脚本，可以处理grub引导时传给内核的参数，使得我能够在grub参数当中指定一个额外的cpio包，这个包当中的内容可以替换小系统当中一些“陈旧”的设置，以便我不需要更新小系统的img镜像文件即可更新实际运行的环境。脚本的名字取名为/etc/update_initrd_fs，然后在/etc/rc3.d/当中增加一个S01update的符号链接指向/etc/update_initrd_fs以便能第一时间更新RAM Disk的文件系统。update_initrd_fs的内容如下：

#!/bin/bash
cmdline=`cat /proc/cmdline`
if [ x"$cmdline" != x ]; then
        tmpvar=${cmdline/*localupdate=/}
        if [ "$tmpvar" = "$cmdline" ]; then
                # no localupdate specification
                echo "no localupdate= string"
                exit
        fi
        tmpvar=${tmpvar/ */}
        if [ "$tmpvar" = "${tmpvar/"@"/}" ]; then
                # no @ in string
                echo "no @ in string"
                exit
        fi
        file=${tmpvar/"\@*"/}
        device=${tmpvar/"*\@"/}
        if [ x"$device" = x ]; then
                # no device
                echo no device
                exit
        fi

        if [ x"$file" = x ]; then
                echo no file
                exit
        fi

        echo update file $file on device $device
        mkdir -p /mnt
        if mount $device /mnt > /dev/null 2>&1; then
                # mount success
                if [ -f /mnt/$file ]; then
                        cd /
                        zcat /mnt/$file | cpio -i -u
                fi
                umount /mnt
        fi
fi

    在grub的配置当中，只需要传给kernel的参数加上localupdate=filename@device这样的格式，例如localupdate=/grub/update.tgz@/dev/sda1即可由这个脚本自动挂载设备并更新数据包。当然，这个脚本也是有一些限制的：
1、更新的数据包需要是cpio的压缩格式，不过你也可以修改倒数第5行的解压命令使之适应其他的格式
2、更新后的文件不一定会生效，例如对/etc/inittab的更新。/etc/inittab的解析是/sbin/init干活的第一步，所以在整个启动过程接近尾声的更新如果涉及到/etc/inittab或者其他的关键驱动更新不一定能够取得效果（例如改变sysinit的级别就无效）。当然，如果是对于/etc/inittab的更新，可以在更新包当中替换/etc/rc.local，在其中执行init q来完成改动。
    总之，这个脚本提供了一种途径，可以使得我们不需要重新对整个initrd.img进行打包就能够获得更新其中部分文件的能力。