标签 GNU 下的文章

C语言项目构建管理辅助工具 – buildc

这几年我一直从事C语言项目的开发。这些项目的规模都不算小,少则十几万代码,多则几十万行代码,至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make工具,构建脚本都是自行编写的,构建时直接在顶层目录下敲入make即可。

这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量;你还要将项目依赖的各种内部公共库、第三方开源库悉数找到,并安装在指定目录下,修改Makefile中这些第三方库的路径配置。只有做完这些后,你才能顺利地执行Make。以后每当你更换一个环境,你就要将上面的步骤重复执行一遍。有的项目第三方依赖较多,要完整地搭建一个项目构建环境所耗费的时间也是很惊人的,特别是对一些不熟悉项目构建的新人更是如此。另外随着产品被要求具备在多个平台上运行的能力,你的构建脚本还要支持在多个平台上的构建,你要为项目所依赖的第三方库准备多个平台的版本;当某个依赖库版本进行了升级,你还要手工在多个环境下进行更新。

为了使项目构建更加容易,我们曾经对Makefile脚本进行了改进,比如自动判断和设定当前顶层路径、自动判定当前项目代码所在的平台,并根据不同平台设定不同的变量值;甚至将项目依赖的第三方库放入subversion服务器,构建项目时通过Shell脚本自动checkout对应平台的依赖库并链接。这些改进都是有效的,但在修改了多个项目后,我们发现了坏味道,那就是在不同项目的Makefile中充斥着大量重复性的脚本代码,这让后续构建脚本的维护十分困难,在一个项目中修正了构建脚本的bug后,很容易遗忘另外几个项目中存在着同样bug。此外每次构建都重新下载项目依赖的第三方库会导致构建变的十分缓慢。

我们在构建中遇到的问题大致就是这么多了。估计很多人会问:你们为何不用autotools生成的configure来生成项目构建脚本?为何不用scons等更加高级的构建工具呢?我的回答是即使使用了这些工具依旧无法解决现有的所有问题。比如利用configure->make可以屏蔽掉一些平台移植的问题,但依旧无法解决第三方库依赖的问题。scons我也试用过,但了解不甚深入,我的印象中它的主要功用是简化构建脚本的编写,让大家从Makefile那纷繁复杂的源文件依赖关系中解脱出来,至于在区别平台以及解决第三方库依赖方面估计也无能为力;另外还有一个原因那就是让大家从已经十分熟悉的构建模式中转到scons的成本也是不小的。

我们的问题其实并非构建脚本的编写问题,而是构建环境的管理问题。autotools和scons所解决的问题属于前者,即构建脚本的编写问题。而解决C语言项目构建环境管理的工具我了解的不多,在互联网上也没有google到。在这方面Java项目倒是有一个很好的工具 – Maven。利用Maven可以做很多事情,我对其了解不多,这里也不多说,但这里提到Maven是因为它的一个Feature启发了我,这个Feature就是对第三方依赖包的管理。虽说C项目依赖的第三方开源包也越来越多,但与Java项目相比那还是小屋见大屋。实际情况是一个Java项目如果不依赖十几个或几十个第三方开源包都不好意思拿出去说。这样一来如果手工找齐这数目庞大的开源包会让Java程序员头痛不已。Maven的这个Feature恰好帮助Java程序员解决了这个难题。Maven可以根据配置自动从互联网上下载指定版本的依赖包,后续Java项目的构建可直接使用已经下载到本地的包;Maven似乎还会定期自动更新第三方包的版本。

受到Maven这个特性的启发,我于是就开发了这款C语言项目构建管理辅助工具 – buildc(项目主页http://code.google.com/p/buildc)。buildc工具本身是用Python语言实现的,这主要是考虑到Python较高的开发效率以及自带功能强大的标准库。这也是我第一次用Python写程序,个人认为buildc的代码十分混乱,内部实现耦合较高,扩展性差,也谈不上什么风格,都是命令式语言的思维,代码本身并没什么价值,以后有时间定会重构^_^。

buildc目前主要实现了两个功能:
1、第三方依赖库的远程获取和本地管理
2、根据目标主机环境、目标主机本地缓存的第三方库情况以及项目本身所依赖的第三方库的最新配置,自动生成一份包含了依赖库环境变量信息的Make.rules文件,或重新更新已有Make.rules文件(上一次由buildc生成的)。项目中的Makefile只需包含(include)Make.rules文件并使用该文件中的变量即可。

buildc的使用是有前提条件的,那就是第三方库必须按特定规划集中存储在一个版本控制服务器中,buildc目前仅支持Subversion。我不是很清楚Maven是如何从互联网上获取对应第三方开源包的jar包的,但我们很难直接获得C第三方库的二进制版本。这里面主要有两点原因:
1、C语言的第三方包多以源码包的形式提供;
2、Java号称"一次编写,到处运行",也就是说Java第三方库仅需提供一份jar包即可运行在多个平台上;但C的二进制库不能,每种平台都会有对应的特定的版本,我们无法将一种二进制库应用到多个平台上。

因此我们首先需要构建组织内部的第三方库集中存储服务器,将各个产品需要的第三方库在各个平台上进行构建,并将得到的静态库或动态库放入版本服务器中。符合buildc要求的二进制库的组织形式如下。比如在svn://127.0.0.1:6666/3rds这个repository下面我们的第三方库按如下组织形式存放:

3rds/
      – libevent/
            – 2.0.10/
                – README
                – source_code_package
                – sparc_32_solaris/
                     – include/
                     – lib/
                – sparc_64_solaris/
                – x86_32_solaris/
                – x86_64_solaris/
                – x86_32_linux/
                – x86_64_linux/
      – netsnmp/
            – 5.2.0/
                …
            – 5.7.0/
                …
      … …

可以看到每个第三方库的组织形式都像下面这样:
package_name/
    – version/
        – CPU_MODE_OS
            – include
            – lib

一旦第三方库都按如此形式存储,buildc就可以获取到该服务器上的二进制库了。前提满足后,我们就来看看buildc在日常构建过程中的使用方法。

一、buildc的安装
buildc目前尚未做成python安装包,只是以源码形式提供的。所以现有情况下只需Checkout或下载buildc源码包到本地即可以使用。

buildc的源码目录结构如下:

buildc*        # 脚本入口
build_utils/   # 源码库
templates/     # Make.rules.in模板
samples/       # 配置样例

为了方便在任意路径下使用buildc,可将存放buildc源码的目录加入到PATH环境变量中去。另外你可能还需执行'chmod u+x buildc'来为buildc加上执行权限。

二、环境初始化
执行buildc init,buildc会在你的HOME目录下建立.buildc.rc文件。该文件用于配置所有可用的第三方库的信息。

$> buildc init
Copy /home/tonybai/proj/build_tools/samples/buildc.rc.sample to /home/tonybai/.buildc.rc OK!
Please config /home/tonybai/.buildc.rc before you use other buildc commands!
Copy /home/tonybai/proj/build_tools/samples/buildc.cfg.sample to ./buildc.cfg OK!
Please config buildc.cfg before you use other buildc commands!

# $HOME/.buildc.rc
foo_repository = ('svn://10.10.0.156:6666/foo',
                       '~/.buildc_libs/foo',
                       [
                        ('snmp', '5.7.0', 'lib/libnetsnmp.a'),
                        ('libexpat', '2.0.1', 'lib/libexpat.a'),
                        ('libiconv', '1.13.1', 'lib/libiconv.a'),
                        ('libevent', '2.0.10', 'lib/libevent.a'),
                        ('lcut', '0.2.0', 'lib/liblcut.a'),
                        ('instantclient', '10.2.0.5.0', 'lib/libnnz10.so')
                       ]
                      )

bar_repository = ('svn://10.10.0.156:6667/bar',
                         '~/.buildc_libs/bar',
                         []
                 )

external_repositories = [
                          foo_repository,
                          bar_repository
                        ]

其中foo_repository和bar_repository分别代表两个可用的集中存储第三方库的服务器,每个repository中的详细配置包括svn repository的url、这个repository的本地缓存路径以及构建所需的该repository中的第三方库信息。

buildc init还会提供一个buildc.cfg配置文件,该配置文件在后面再细说。

三、第三方库的本地缓存管理
有了正确的.build.rc配置,我们就可以初始化第三方库在本地的缓存了,执行buildc cache init。

$> buildc cache init

===>Begin init repository [svn://10.10.0.156:6666/foo]
Create dir: /home/tonybai/.buildc_libs/foo
library [snmp] does not exist!
Checkout [svn://10.10.0.156:6666/foo/snmp/5.7.0/x86_64_linux]…
Checkout [svn://10.10.0.156:6666/foo/snmp/5.7.0/x86_64_linux] OK!
library [libexpat] does not exist!
Checkout [svn://10.10.0.156:6666/foo/libexpat/2.0.1/x86_64_linux]…
Checkout [svn://10.10.0.156:6666/foo/libexpat/2.0.1/x86_64_linux] OK!
… …

buildc cache init命令会根据.buildc.rc中的配置,从各个repository中下载对应该主机平台的第三方库,存放在对应的缓存路径下备用。

如果repository有更新,我们可以执行buildc cache update来更新本地缓存(在实际的日常开发过程中你可以将该命令加入到crontab中来定期自动更新本地缓存):
$ buildc cache update

===>Begin update repository [svn://10.10.125.156:3560/3rds]
Update [snmp]…
Update [snmp] OK!
Update [libexpat]…
Update [libexpat] OK!
… …

当不需要本地缓存时,我们可以通过buildc cache remove删除之:
$> buildc cache remove

===>Begin remove repository [svn://10.10.0.156:6666/foo]
Remove [/home/tonybai/.buildc_libs/foo] OK!
<=== End remove repository [svn://10.10.0.156:6666/foo]
… …

四、生成项目Make.rules
第三方库的本地缓存建立好后,我们就可以来配置项目了。在前面执行完buildc init时,buildc生成了一个项目配置模板文件buildc.cfg(.buildc.rc和buildc.cfg本身也都是Python源文件),我们将该文件移到项目的顶层目录下,然后对该文件进行配置,下面是一个例子:

#(proj_name, (major, minor, revision), author)
project = ('foo', (1, 3, 1), 'tonybai')

# [(libname, libversion, [archives*])*]
external_libs = [
 ("snmp"  , "5.7.0", ["libnetsnmpagent.a", "libnetsnmphelpers.a", "libnetsnmpmibs.a", "libnetsnmp.a"]),
 ("libexpat" , "2.0.1", ["libexpat.a"])
]

# [def*]
# e.g. ['-Dprint_msg=printf', '-D_SELF_DEBUG_']
custom_defs = [
                '-Dprint_msg=printf',
                '-Derr_msg=printf'
              ]

# [(var, value)*]
# e.g. [ ('WITHOUT_DB_IMPORT', 'TRUE'), ('SUPPORT_MYSQL', 'TRUE') ]
custom_vars = [
                ('WITHOUT_IMPORT', 'TRUE'),
                ('WITHOUT_NM', 'TRUE')
              ]

# [include_path*]
# e.g. ['./include', '/home/tonybai/.include']
custom_includes = [
                    './include'
                  ]

# [(lib_path, [archives])*]
# e.g. [('/home/tonybai/.lib', ['libfoo.a', 'libbar.so']), (‘.libs’, ['libzoo.a'])]
custom_libs = [
                ('.libs', ['libfoo.a']),
                ('', ['libzoo.so'])
              ]

这里简要说明一下这个配置文件的各个配置项:
* external_libs是项目所使用的第三方库列表,这些第三方库必须存在于该主机的本地缓存中,也就是.buildc.rc中拥有这些库的配置;
* custom_defs是项目需要额外传递给编译器的命令选项集合;
* custom_vars是你想额外在Make.rules定义的变量集合;
* custom_includes是额外需要单独指定的的头文件包含路径集合;
* custom_libs是项目所需额外的(不在本地第三方库中存储的)库路径,比如一些系统库。

完成buildc.cfg的配置,我们就可以通过buildc config-make来生成Make.rules文件:
$ buildc config-make
Can not found Make.rules in current directory!
Generate [/home/tonybai/proj/foo/Make.rules] …
Config [/home/tonybai/proj/foo/Make.rules]…
Config [/home/tonybai/proj/foo/Make.rules] OK!
Generate [/home/tonybai/proj/foo/Make.rules] OK!

生成的Make.rules如下:
#
# Make.rules for foo
#
# tonybai
# 2011-12-08
#
# @Generated by buildc@
#

# Project information
TOPDIR = /home/tonybai/proj/foo#@topdir@

# Platform information
OS = linux#@os@
CPU = x86#@cpu@
CMODE = 64-bit#@cmode@

# Version information, (MAJOR.MINOR.REVISION)
MAJOR = 1#@major@
MINOR = 3#@minor@
REVISION = 1#@revision@
VERSION = $(MAJOR).$(MINOR).$(REVISION)

# Compiler options
DEFS = -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_DEBUG_ -DVERSION=\"${VERSION}\"
… …
CUSTOM_DEFS = -Dprint_msg=printf -Derr_msg=printf #@custom_defs@
CC = gcc -m64#@cc@
CFLAGS = $(FDEBUG) $(FWALL) $(FPIC) $(FOPTIMIZE) $(DEFS) $(CUSTOM_DEFS) $(INCLUDES)

# Library infomation
snmp_ROOT = ~/.buildc_libs/foo/snmp/5.7.0/x86_64_linux#@lib_roots@
libexpat_ROOT = ~/.buildc_libs/foo/libexpat/2.0.1/x86_64_linux#@lib_roots_end@

LIB_INCLUDES = -I $(snmp_ROOT)/include -I $(libexpat_ROOT)/include #@lib_includes@
LIBS_DEPEND =  -L $(snmp_ROOT)/lib -lnetsnmpagent -lnetsnmphelpers -lnetsnmpmibs -lnetsnmp -L $(libexpat_ROOT)/lib -lexpat#@ libs_depend@
CUSTOM_LIBS = -L .libs -lfoo -lzoo#@custom_libs@

# Headers
DEFAULT_INCLUDES = #@default_includes@
CUSTOM_INCLUDES = -I ./include #@custom_includes@
INCLUDES = -I $(TOPDIR)/include $(LIB_INCLUDES) $(CUSTOM_INCLUDES) $(DEFAULT_INCLUDES)

# Libraries
DEFAULT_LIBS = #@default_libs@
LIBS = $(LIBS_DEPEND) $(CUSTOM_LIBS) $(DEFAULT_LIBS)

# Other definitions
WITHOUT_IMPORT = TRUE#@custom_vars@
WITHOUT_NM = TRUE#@custom_vars_end@
… …

你可以对比着项目buildc.cfg的配置来查看Make.rules的构成。如果bulidc.cfg配置发生变化,那么再次执行buildc config-make会更新当前路径下的Make.rules。Make.rules的生成和更新使用了基于模板的标记替换技术。

五、利用Make.rules构建项目
可以看出Make.rules中将平台信息和第三方库的依赖信息都放置在对应的变量中了。项目的Makefile只需要包含Make.rules便可以利用这些信息进行项目的构建。可以利用的Make.rules中的主要变量包括:CFLAGS、LIBS。我们甚至可以为项目再编写一个"一键构建"脚本,该脚本中只需包含两行代码即可:

buildc config-make
make

你无需将Make.rules提交到源码版本库中,但需要将buildc.cfg作为项目的一部分。这样在任一一个通过buildc做项目构建管理的环境中,你的项目就都可以进行"一键式"构建了,再也无需为配置项目路径和寻找构建第三方依赖库而发愁了。另外通过buildc进行构建管理的项目将会很容易地集成到持续集成过程中。

buildc与make的组合模式很类似于maven和ant的组合,但buildc目前的功能还无法与maven相比,不过buildc也不打算做成maven的模样。buildc后续可能会支持从更多种版本管理服务器(比如git)下载第三方库,支持按指定模板生成Make.rules(目前只有一种模板)等特性。从目前实践的情况来看,buildc这个项目构建管理辅助工具十分适合我们内部的C项目构建,也许它也同样适合你的项目,有兴趣的朋友不妨试试。

使用autoconf解决可移植性问题

昨天在编译项目代码时遇到了这样一个错误:

xx_base.h:72:2: 错误:#error "One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined."

这是预编译器的错误输出。原因很明显:预编译器在处理xx_base.h时没有发现_BIG_ENDIAN或_LITTLE_ENDIAN的定义,#error预处理宏输出了如上错误。下面是出现错误位置的源码片断:

/* xx_base.h*/
#if defined(_BIG_ENDIAN)
… …
#elif defined(_LITTLE_ENDIAN)
… …
#else
#error "One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined."
#endif

xx_base.h是部门一基础库中的一个头文件,上面的做法对于基础库自身来说并无太大问题。基础库的Makefile通过检测CPU类型定义了对应的字节序宏,并在编译时作为gcc的命令行选项传入:

/* Makefile */
ifeq ($(CPU), x86)
        DEFS += -D_LITTLE_ENDIAN
else ifeq ($(CPU), sparc)
        DEFS += -D_BIG_ENDIAN
else
        $(error $(CPU) is not supported!)
endif

但是一旦这个基础库被某项目复用,且该xx_base.h文件被项目代码引用,编译就会出现问题,因为各个项目的Makefile中并没有定义_LITTLE_ENDIAN或_BIG_ENDIAN宏。如果基础库不做修改,那么复用该基础库的项目代码中就都需要考虑这两个宏的定义问题。这未免有些"强加"的意味,对于一个几乎被所有项目复用的基础库而言,这样的做法显然不妥。

那如何解决这个问题呢?一个思路是如果基础库在发布后依旧携带这些宏的定义,那就可以避免这样的问题了。在很多使用autotools(包括autoconf, automake, libtool等)协助进行代码构建的开源包中经常会看到一个名为config.h的源文件,那里面包含了与移植相关的宏定义。这个config.h是configure脚本根据config.h.in模板自动生成的。

我们的基础库如果完全用autotools改造显然也可以解决这个问题,但这样一来以前编写的一些构建脚本就要被全部抛弃,能否折中一下呢:利用autoconf生成config.h,但不输出Makefile,依旧使用原先的Makefile?

实验证明这样是可以的。只需对configure.in(或configure.ac)做一些调整即可,将类似AC_CONFIG_FILES([Makefile src/Makefile src/example/Makefile])这样的代码从configure.in中移除即可:

#                                               -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.64])
AC_INIT([baselib], [1.0.0], [xx@gmail.com])

AC_CONFIG_HEADERS([include/config.h])

# Checks for header files.
AC_CHECK_HEADERS([stddef.h stdlib.h string.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_TYPE_SIZE_T

# Checks for library functions.
AC_FUNC_MALLOC
AC_CHECK_FUNCS([memset])

AC_OUTPUT

AC_CONFIG_HEADERS这句是关键!修改完configure.in后,执行autoheader,我们就会在include下发现config.h.in模板文件被生成了出来。执行autoconf生成的configure脚本后,我们在include下就得到了config.h。

下面就是在config.h中加入我们期望的宏。在我们的问题中,我们希望在configure时可以探测到当前host所用的字节序(endianess),并将结果反映到config.h中。幸运的是autoconf内置了字节序的测试宏AC_C_BIGENDIAN。增加了AC_C_BIGENDIAN测试宏的configure.in经过autoheader处理后得到的config.h.in文件中多了如下这组代码:

/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
   significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
#  define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
#  undef WORDS_BIGENDIAN
# endif
#endif

在Sun SPARC小机上运行configure,我们得到的config.h中有关字节序的宏定义代码如下:
/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
   significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
#  define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
#  define WORDS_BIGENDIAN 1
# endif
#endif

config.h中定义了WORDS_BIGENDIAN宏,说明Sun Sparc小机采用的是BigEndian。这样只要基础库的头文件都在最开始包含了config.h,那么上面的问题就解决了。

不过有些朋友不喜欢WORDS_BIGENDIAN这个宏的命名,想自己给标识字节序的宏命名,比如BASELIB_IS_BIGENDIAN。那么我们如何来支持呢?这里我也找到了一个办法:

首先,就是手工编辑config.h.in(注意这之后你就不要通过autoheader生成config.h.in了),在结尾加上这样一行:
#undef BASELIB_IS_BIGENDIAN

然后,修改configure.in,通过AC_DEFINE来定义一个新的BASELIB_IS_BIGENDIAN宏:

AC_C_BIGENDIAN
if test $ac_cv_c_bigendian = yes; then
    AC_DEFINE(BASELIB_IS_BIGENDIAN, 1)
fi

我们通过AC_C_BIGENDIAN的检测结果来确定是否定义BASELIB_IS_BIGENDIAN宏,ac_cv_c_bigendian显然是AC_C_BIGENDIAN内置的一个变量,如果需要,我们也可以模仿其命名规则得到其他测试宏内置的变量。

最后,执行autoconf和configure,我们就可以在include/config.h的结尾看到这样一行定义:
#define BASELIB_IS_BIGENDIAN 1

AC_DEFINE不一定非要与测试宏绑定在一起,它的用法很灵活。如果我们的代码中需要根据不同操作系统的类型来调用不同的代码,那么我们需要在config.h中放置几个标识操作系统类型的宏,比如BASELIB_LINUX和BASELIB_SUNOS。和BASELIB_IS_BIGENDIAN一样,我们首先需要手工编辑config.h.in,增加如下两行代码:

#undef BASELIB_LINUX
#undef BASELIB_SUNOS

然后,修改configure.in,加入自定义的OS测试代码,并且定义对应的宏:

os=`uname -s`
case $os in
    Linux)
        AC_DEFINE(BASELIB_LINUX, 1)
        ;;
    SunOS)
        AC_DEFINE(BASELIB_SUNOS, 1)
        ;;
    *)
        AC_ERROR([host is unsupported.])
        ;;
esac

最后,执行autoconf和configure。如果我们在redhat上,我们就会在config.h中看到如下代码:

#define BASELIB_LINUX 1
/* #undef BASELIB_SUNOS */

autoconf也内置了一系列系统类型测试宏,比如AC_CANONICAL_SYSTEM(依赖install-sh、config.sub和config.guess三个脚本),其测试后的结果放在了$host变量中,你也可以通过判断$host变量来确定到底在config.h中定义哪个宏。

偿还N年前的一笔技术债

记得刚来公司时曾参与过一个项目,项目中用到了部门基础库中的一个B+树接口。不过在程序调试过程中我们发现可执行程序总是dump core(在sparc solaris上),经初步分析,断定问题就出在B+树接口处,但一时又找不到问题原因。还好这个B+树的实现者就坐在我的旁边。他分析后告诉我:这个B+树接口要求用户自定义的索引结构体的size应该为4的整数倍。按照他的说法,我为结构体打了padding,以满足结构体size为4的整数倍的要求。修改后果然不再dump core了。当时项目进度紧,我也没有求甚解,这件事也就过去了。

一晃N年过去了。今天在做程序的64位移植过程中我再次遇到了这个问题。问题的表象就是程序运行时dump core,通过gdb或pstack查看core的内容,发现程序是在B+ Tree初始化时出的core。显然这又是一个内存违规访问的问题,且在Sparc上出现(x86 Linux上运行正常)十有八九与内存对齐有关。

B+ Tree出问题首先让我想到了N年前的那个解决方法。我先查看了自定义的索引结构体(usr_idx):

struct usr_idx {
    unsigned int usr;
};

不过sizeof(usr_idx)无论是32bit编译还是64bit编译,其值都是4。那按照B+树原作者的说法,这显然不足以让B+树出现问题。事实也的确如此,32bit编译的程序在Sparc Solaris下运行良好,只是目前改为了64bit编译,才dump core,那问题到底出现在哪呢?

到这里,我也只能从代码着手了,把N年前没弄清楚的原因找出来,顺便也把这个存在了N年的Bug彻底解决掉,把这笔技术债还了。pstack的输出告诉我问题出在一个名为bptree_create_node的函数中,嫌疑最大的一处代码大致是这样的:

for (i = 0; i rank; i++) {
    (elem_base(tree, tmp_bn, i))->key = key_base(tree, tmp_bn, i);
    (elem_base(tree, tmp_bn, i))->pointer = NULL;
}

直觉告诉我问题出在elem_base这个宏里,elem_base的定义如下:

#define elem_base(tree, eb, index) ((xx_bptree_elem*)((char *)&(eb)->e_base.mw_cp + ((SIZEOF_bptree_elem + (tree)->keysize))*(index)))

很显然这个定义最终是想得到一个xx_bptree_elem*类型的指针。从内存地址角度来说,我们会得到了一个内存地址,且这个地址被认为是一个xx_bptree_element元素的起始地址。那么是否所有地址作为xx_bptree_element元素的起始地址都合法呢?答案是不一定,至少在Sparc平台上不是所有地址都可以作为xx_bptree_elem的起始地址的。

那么什么样地址可以作为xx_bptree_element的起始地址呢?在Sparc上这取决于结构体的对齐系数。xx_bptree_elem结构的定义如下:

union mem_word {
    void  *mw_vp;
    void (*mw_fp)(void);
    char  *mw_cp;
    long   mw_l;
    double mw_d;
};
typedef union mem_word mem_word;
#define SIZEOF_mem_word (sizeof(mem_word))

struct xx_bptree_elem {
    void       *key;
    void       *pointer;
    mem_word   base;
};
typedef struct xx_bptree_item xx_bptree_item;
#define SIZEOF_bptree_elem        (sizeof(xx_bptree_elem)-sizeof(mem_word))

在32bit编译的情况下,系统默认对齐系数为4(参见/usr/include/sys/isa_defs.h中的宏_MAX_ALIGNMENT),则该结构体的对齐系数 = min(max(sizeof(key), sizeof(pointer), sizeof(base)), 4) = 4。这样xx_bptree_elem在32bit下的有效起始地址为可被4整除的内存地址。

而在用64bit编译时,系统默认的对齐系数为16(同参见isa_defs.h),但由于xx_bptree_elem中size最大的字段(base)的size为8,则结构体的对齐系数就等于8。即xx_bptree_elem元素的有效起始地址为可被8整除的地址。

好了,我们再回过头来看看elem_base宏在不同编译情况下能否总是返回合法的地址。

#define elem_base(tree, eb, index) ((xx_bptree_elem*)((char *)&(eb)->e_base.mw_cp + ((SIZEOF_bptree_elem + (tree)->keysize))*(index)))

这个宏中有三个元素决定返回地址,分别是"基址":&(eb)->e_base.mw_cp、偏移量SIZEOF_bptree_elem和(tree)->keysize。其中基址是另外一个结构体xx_bptree_node中一个mem_word类型字段的地址,你知道的,mem_word这种手法可以保证其起始地址严格按照其内部最大字段的对齐系数对齐的,也就是说mem_word的对齐系数与double的对齐系数一致,即无论是32bit编译还是64bit编译,其对齐系数都是8,也就是说我们可以确保这个”基址“是可以被8整除的;至于偏移量SIZEOF_bptree_elem,我们可以直接可以得出其大小:

32bit下,SIZEOF_bptree_elem = 8
64bit下,SIZEOF_bptree_elem = 16

可以看出无论是32bit还是64bit编译,SIZEOF_bptree_elem的值都是8的倍数;显然这两个值都不会影响elem_base最终返回地址的合法性。

现在剩下的就是(tree)->keysize了。keysize是由xx_bptree_init接口传进来的,它在上层实际上就是用户自定义的索引结构体的大小,显然这个大小不一定就是8的倍数。在我们的系统中,keysize = sizeof(usr_idx) =
4。这个keysize在32bit编译下是没有问题的,因为32bit编译只需要elem_base返回的地址可以被4整除即可,这也是为什么我们的程序在32bit编译下运行正常的原因。回想一下N年前的那个问题,其真正原因也就在这里:当时我定义的索引结构体的大小无法被4整除。在64bit编译下,keysize显然不能满足被8整除的要求,导致elem_base返回的地址只能被4整除。而xx_bptree_elem这个结构体的地址是严格要求必须可被8整除的。将一个只能被4整除而不能被8整除的地址强制转换为xx_bptree_elem元素地址并通过该强制类型转换后的地址访问xx_bptree_elem内部的元素显然就会导致core的出现了。

现在看来当初我的同事并未真正理解该B+ tree为何要求用户自定义结构体的大小必须为4的整数倍了,他只是通过现象得到了那条经验罢了,这笔技术债务也就从那时留了下来。

解决该问题并不难,作为基础库,我们无论如何都不应该依赖用户的自觉,我们在接口实现中增加一个转换就可以解决这一隐藏了若干年的Bug,将外面传入的keysize经align_word转换后再赋给tree->keysize,这样就可以保证elem_base始终返回合法的地址了。

突然想起了那句话:”出来混,总是要还的“,我们欠的技术债务也不例外。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多