TCMalloc的全局分配器，处于TCMalloc的最底层，负责向操作系统申请和释放内存，接口有两个，定义在src/system-alloc.h|.cc：1 2 3externvoid*TCMalloc_SystemAlloc(size_tbytes,size_t*actual_bytes,size_talignment=0);externboolTCMalloc_SystemRelease(void*start,size_tlength);TCMalloc_SystemAlloc的参数，除了要申请的大小bytes，还有actual_bytes和alignment，因为对齐的需求，该接口可能分配大于bytes的内存，实际大小保存在actual_bytes。TCMalloc_SystemRelease负责『释放』内存，至于释放为什么加引号，下面会提到。接下来，介绍下这两个接口的实现。malloc-extension.h里面，定义了接口类SysAllocator，该类只有一个接口：1 2 3 4 5 6classSysAllocator{public:SysAllocator(){}virtual~SysAllocator();virtualvoid*Alloc(size_tsize, ...继续阅读 (18)

场景：一个多线程服务器，每个线程执行一个事件循环。在事件循环开始前，调用socket/bind/listen监听端口，然后将监听句柄（fd）添加到epoll，然后开始事件循环，执行epoll_wait。epoll_wait返回有效事件时，对于监听事件，调用accept建立新连接，将该连接句柄添加到epoll；对于普通连接，调用read/write进行网络IO及其他处理逻辑。现象：服务器进程CPU占用彪高，几乎每个事件循环都在accept，客户端出现超时。原因：ulimit -n为65535， 进程打开的fd已经超过该数值，导致accept时无法取得fd而失败，而此时TCP连接的三次握手已经建立。又因为epoll使用的LT触发模式，该连接事件会不停地由epoll上报，于是产生了所谓的『死循环』，其实是事件循环闲不下来了，即使没有实际的 网络 IO。 ...继续阅读 (19)

没几天，你的程序出炉了，加以时日，回归测试也完成了，你兴冲冲地想，啊哈，终于可以上线给东家挣钱啦！有一天，你的程序 core dump 了，光荣地被谋杀在战场的某个小小小角落。你战战兢兢地打开了 GDB，妄图勘察现场，习惯性地按下 bt，看到了下面的一幕：#0 0x0000000000000078 in ?? () #1 0x000014473a087d0a in ?? () #2 0x00007f66db85b351 in ?? () #3 0x0000000000000025 in ?? ()WTF! 栈乱掉了，满眼的疑问号：你的小宝贝她从哪里来？要到哪里去？当时在搞什么？在被谁搞？怎么样？现在知道栈是多么伟大多么重要的一个东西了吧。它只在程序运行时候被创建，保存了函数的参数、局部变量和调用关系，以至于在进程异常死亡时 OS 把他留下来，存到磁盘上。现如今，它被糟践成这副德性，怪得了谁呢？要么是你的编译器抽抽了，要么就是你脏心烂肺内存写越界了。不信，请 call 一下 foo：1 2 3 4voidfoo(){inta[1];memset(a,0,1024);}能恢复吗？抱歉，IA32 下，调用链比较规整，根据情况 hack 一下 core 文件，还有一线生机。但是，在 IA64 里，rbp 可能已做它 ...继续阅读 (6)

set follow-fork-mode child，被调试进程执行fork时，自动 attach；set scheduler-locking on，调试时，禁用线程切换，可选 on/off/step，默认 off；symbol-file target.debug，添加独立的 debuginfo 文件；i sharedlibrary，查看共享文件映射信息；add-symbol-file libxx.debug ADDRESS，添加共享文件的 debuginfo 文件，ADDRESS 是共享文件的映射始址，由i sharedlibrary获得；gcc test.cpp -g -g3，调试信息中保留 MACRO；set logging on，GDB 的所有输入/输出都会被写入当前目录下的 gdb.txt；set print pretty on，打印对象，尤其是结构体时，格式更加友好；p $rip，打印 rip 寄存器；i reg，查看寄存器集，i registers-all显示全部寄存器；display/i $rip，每次断点，打印下一条指令；l *0x608048，显示某指令地址对应的代码行，可执行文件包含调试信息时，亦可用 addr2line；x/40a $rsp，以地址形式打印 stack，栈乱掉时可救命；return 0，停止调试当前函数，并以指定值返回；p {tair::St ...继续阅读 (13)

不必说静态变量和普通变量的区别，也不必说静态变量及其作用域的得与失，单单说一下函数作用域的静态变量是如何初始化的。1 2 3 4 5 6intfoo(){staticintn=init();//~ do anything/nothing on 'n'returnn;}在 foo() 第一次被调用时，foo()::s 只初始化一次（C 中，静态变量只允许以常量初始化）。“只初始化一次”是如何保证的呢？当然需要编译器维护一个状态，来标识该变量是否已被初始化，并安插代码，在每一次函数被调用时进行判断。咱们通过汇编验证一把：1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26.globl _Z3foov.type_Z3foov,@function _Z3foov:.LFB1405:pushq%rbp.LCFI13:movq%rsp,%rbp.LCFI14:movl $_ZGVZ3foovE1n,%eaxmovzbl(%rax),%eaxtestb%al,%aljne.L18 movl $_ZGVZ3foovE1n,%edicall__cxa_guard_acquire testl%eax,%eaxsetne%altestb%al ...继续阅读 (14)

多线程程序中，默认情况下各个线程的名字与进程名相同，但是可以通过操作系统提供的接口(prctl)修改这个名字。方法很简单，但某些时候，可以给程序的调试和运维带来很大的帮助。最近在调优tair的proxy server，其中使用到了tair client，每个tair client会创建若干个线程用于网络IO，另外proxy server本身还有其他IO线程。压测过程中发现，某个线程CPU彪到了100%，其他线程只有50%左右。根据该线程的调用栈可以推测出是tair client的IO线程，但其他IO线程不好分辨属于tair client还是proxy server。将IO线程按照功能命名后，发现4个tair client IO线程中，一个线程跑满了所在CPU核心，其他三个一直处于空闲状态。因此可以推断出tair client在连接分配上存在问题……找到了问题根源，解决起来就很容易了。给当前线程命名的一个例子：1 2 3 4 5 6 7 8#include <sys/prctl.h>voidset_thread_name(constchar*prefix){staticintindex=0;charthname[16];snprintf(thname,sizeof(thname),"%s%d", prefi ...继续阅读 (23)

最近看了些Memory Barrier的东西，针对一个经典的示例程序，做了重现性测试。对这个程序原型做一个简要介绍：有全局变量x/y/r1/r2，初始值均为0；线程1执行x = 1; r1 = y; 线程2执行y = 1; r2 = x。从“程序员角度”，在两个序列执行过后，r1 == r2 == 0不可能成立。但当发生执行时“访存重排序”时，却可能出现r1/r2同时为0的情况。使用CPU内存屏障适当“隔离”访存操作，杜绝重排序，就可以确保程序得到预想的结果。1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58//~ reordering.cpp#include <semaphore.h>sem_t begin1;sem_t begin2;sem_t end; volatileintx=0, y=0, r1=0, r2=0; void*thread1(void*){while(true){sem_wait(&be ...继续阅读 (11)

今天通过酷壳一篇推荐了解了一下Cache 的“伪共享”(False Sharing). 写了小程序做了个简单的测试：1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55//! false_sharing.cpp#include <iostream>#include <pthread.h>#include <sys/time.h>usingnamespacestd; template<size_tNPAD,size_tNTH=4,size_tNLOOP=(1<<30)>classFalseSharing{public:voidrun(){structtimeval b, e;gettimeofday(&b,NULL);pthread_t threads[NTH];for(size_ti=0;i<NTH;++i){pthread_create ...继续阅读 (3)

经常需要查看一个文件有多少页面驻留在物理内存中，Linux中没有找到现成的命令，自己动手写了个小工具，基于mincore(2)系统调用。代码放在Github上面，可以git clone git://github.com/dutor/mincore.git获取。目前可用选项有限：查看特定文件驻留物理内存的页面数/字节数；将文件全部加载到物理内存；递归地查看某个目录下所有文件的映射情况。其他需要的功能，可能在以后添加。$ ./mincore -h mincore [options] <-p file or directory> -h --help print this message. -p --path path to file or directory you want to inspect. -t --touch whether to touch pages of the file, in order to load them into memory. $ ./mincore -p /lib64/libc.so.6 /lib64/libc.so.6: page count: 420, cached: 408 file size: 1717800(1677K), cached: 1668648(1629K) $ ./mincore -p /lib64/libc.so. ...继续阅读 (28)

偶然发现glibc提供的libc.so是“可执行的”，这是快速查看glibc版本的一种方法，1 2 3 4 5 6 7~$/lib/i386-linux-gnu/libc.so.6 GNU C Library(Ubuntu EGLIBC2.13-20ubuntu5.1)stable release version2.13, by Roland McGrath et al. Copyright(C)2011Free Software Foundation, Inc. ... Compiled by GNU CC version 4.6.1. Compiled on a Linux 3.0.17 system on2012-03-07. ...这是gcc提供的一种叫做PIE（Position Independent Executable）的特性，可以创建位置无关的可以执行对象。它可以像共享库一样被加载到任何地址上执行。使用gcc的PIE相关选项可以创建这种共享库：1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20//~ echo.c#include <stdio.h>voidecho(constchar*s){printf("%s\n",s); ...继续阅读 (5)

事情是这样的。我们对tair（淘宝的分布式Key/Value系统）动了一次大手术，更换了网络框架，经过长时间的测试/调试，终于完全通过了回归测试。但要打包发布的时候，却发现服务器可以正常启动，但却完全无法接受请求。调试无果，对比打包前后程序的差异，仅在于是否使用-O2选项对程序进行编译优化。无头苍蝇一样，Google搜索“gcc optimization problems”，找到StackOverflow上面的这个帖子，“抱着试试看的心态”，在编译选项中加入-fno-strict-aliasing，bingo！-fno-strict-aliasing这个选项是做什么的？aliasing又是什么？C和C++的标准给出了说明：Strict aliasing is an assumption, made by the C (or C++) compiler, that dereferencing pointers to objects of different types will never refer to the same memory location (i.e. alias eachother.)即是说，在strict aliasing规则下，C/C++编译器认为，“不同类型”的指针（准确说是lvalue）一定不会引用同一个内存区域（即aliasing）。在这个规则的前提下， ...继续阅读 (17)

pthread的mutex通常用在多线程的同步当中，至于多进程的同步，一直以为只能使用记录锁和信号量，而这两种机制都需要内核的支持，属于“重量级”部件。也曾经在多进程同步中使用pthread mutex，但前提有两个：mutex能为多个进程所见，使mutex对象驻留在共享内存中；mutex本身不额外使用进程本地的内存，如堆内存。第一个前提容易满足，对于第二个，GCC的pthread实现也满足。但我一直没有注意到的是，pthread mutex标准本身对多进程提供了“可选”支持，只要实现支持、初始化mutex时pthread_mutexattr_t的pshared成员置为PTHREAD_PROCESS_SHARED即可。pshared默认为PTHREAD_PROCESS_PRIVATE，即仅支持单进程。如果mutex驻留于共享内存，但pshared为PTHREAD_PROCESS_PRIVATE，此时多进程操作该mutex的行为是未定义的。这两天在写一个多进程可访问的库时就出现了这种“未定义”的行为，花费了一个多工作日才找到原因。多进程使用mutex需要的基本操作如下：1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29#include <pthread.h>#inclu ...继续阅读 (5)

看下面程序有什么问题？1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26classX{public:X(){h();}virtual~X(){}virtualvoidf()=0;voidh();};voidX::h(){f();}voidX::f(){} classY:publicX{public:Y(){}voidf(){return;}};intmain(){Y y;return0;}这个呢？1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24classX{public:X(){}virtual~X(){}virtualvoidf()=0;}; c ...继续阅读 (11)

这么一段程序，1 2 3 4 5 6 7 8 9typedef__gnu_cxx::hash_map<object*, object*, object_equal_to, object_hasher>object_hash_map_t;object_hash_map_t hash_map;hash_map.insert(make_pair(newobject,newobject));object_hash_map_t::iteratorit=hash_map.begin();while(it!=hash_map.end()){deleteit->first;deleteit->second;++it;}该程序core而不止。因为STL的代码很多都被内联了，调试起来不方便，于是看了下sgi的STL实现，发现了问题。首先，STL的hash_map是由hashtable实现的，hash_map只是对hashtable的一个封装。hashtable也只是很普通的实现，使用单链表解决冲突。下面是hashtable中对迭代器的operator++操作的实现，1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19struct_Hash ...继续阅读 (21)

本菜鸟写了一个server，经长时间激烈的测试以后，终于要在测试环境供外部使用了。经过一天激烈的打包，一枚rpm终于诞生了。上传到公司的yum包仓库，当PE同学部署时遇到了问题。程序在启动过程中莫名地core掉了，屡试不爽。使用gdb查看core文件的程序堆栈，发现程序core在了一个我从来没有修改过的类的析构函数中，core的直接原因就是C/C++程序员的老朋友Segmentation fault同学。查看该析构函数，里面只做了两个操作，简单讲，就是释放对象内存的两个delete。其中一个对象是在类的构造函数中创建，另外一个对象是在其他初始化函数startup中创建。析构函数中理所当然地对这两个对象的指针进行判断，非NULL则delete。这个类很特殊，正常情况下需要调用startup进行初始化，然后作为一个持久的对象使用。也可以不进行初始化，调用其他接口，然后销毁。我使用该类的场景就属于后者。在之前的测试过程中，core dump从未发生。使用下面的代码简单地描述这个场景：1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23classFOO{public:FOO(){p=newObject;}~FOO(){if(p)delet ...继续阅读 (17)

lsof, LiSt Opened Files, 列出打开的文件, 听起来很简单的样子. 但想*nix中很多其他工具一样, lsof把这件简单的事情做到了炉火纯青. 因为Unix认为”一切皆文件”, 那么”打开的文件”就不仅仅是传统意义上打开的文件了, 还可以是网络/Unix域套接字, 匿名/具名管道, 共享库文件, 目录文件, 设备文件等等. 很多场景下, 查看进程或系统打开的文件会给调试带来极大的帮助. 下面简单地介绍lsof常被使用的功能选项.lsof: 简单地执行lsof会列出当前系统中所有被打开的文件, 但为了看到完整的信息, 通常需要具有root权限;lsof -u dutor: 列出用户dutor打开的文件, 可指定多个用户, 默认是OR的关系;lsof -c tair: 列出名称以tair开头的进程打开的文件, c for command, 可指定多个;lsof -c /^t.*r$/: 列出名称以t开头, r结尾的进程打开的文件;lsof -p 12315: 列出进程号为12315的进程打开的文件, 可指定多个;lsof server.log: 列出打开server.log文件的进程, 可指明多个文件;lsof .: 列出打开当前目录的进程;lsof +D .: 递归地列出当前目录中被打开的文件, 当然也可以lsof ...继续阅读 (12)

前几天，在组内分享了关于链接器的一些东西，在这里总结一下。讨论的背景主要是基于C/C++，Linux平台相关。链接器相关的一些基本问题学习或者了解链接器，有一些基本的问题需要关心：链接器做些什么；链接器和体系结构；程序是怎样生成的。下面做简要介绍。链接器做些什么链接器之所以存在或者产生，基本上是由于程序开发的模块化。这里讲的模块，主要是编译概念上的模块，通常他们按照功能划分，比如一个.c或者.cpp文件就是一个编译单元，就是一个模块，编译后就产生一个.o目标文件。为了最终生成一个可执行文件、静态库或者动态库，就需要把各个编译单元按照特定的约定组合到一起。这里特定的约定指的就是“目标文件格式”，它定义了目标文件、库文件和可执行文件的格式，这里组合这一过程就叫做链接。一个编译模块中，通常是函数的定义和全局数据的定义，数据类型的定义通常在头文件中，编译时会被包含在编译模块中。函数和数据由符号来标识，一般符号有全局和静态之分，全局符号可以被其他模块引用，而静态符号只能在本模块中引用。编译各个模块时，编译器会解析该模块。重要的一项工作就是建立符号表，符号表中包含了本模块有哪些符号可以被其他模块引用（导出符号），还包括本模块引用（导入符号，即未定义符号）、但在其他模块中定义的符号。每一个符号都关联一个地址，这个地址指明了该符号在本模块中的偏移地址（通常是一个从0开始的地址）。链接器在链接过程中 ...继续阅读 (4)

Windows下面的有几个比较好的虚拟终端，比如对个人免费的XShell和收费的SecureCRT，如果平时有很多机器需要ssh远程操作，使用这些工具是很方便的（Putty很小巧，但功能相对较若）。但Linux平台下，我没找到类似的工具。虽说有原生的ssh命令，但如果有大量的主机需要登录，还是有些捉襟见肘。然后，脚本就又来拯救世界了。脚本很简单，1 2 3 4 5 6 7 8 9 10 11 12 13 14#! /bin/bash declare-AHOSTS   HOSTS[devel]="10.232.35.40"HOSTS[test]="10.232.36.200"USER="dutor"PS3="host to connect> " selectiin"${!HOSTS[@]}"dossh$USER@${HOSTS[$i]}break;done脚本中用到两个bash“不太常用”的特性，关联数组和select菜单。select可以向用户提供一个菜单试的交互界面，语法结构类似于for。关联数组只是一种特殊的数组，这里有一个简单实用的总结。关于ssh还有两点需要说明一下。若想登录时免去输入密码，只需要在目标主机上相应用户的~/.ssh/authorized_keys中追加本地主机的公共密钥即可。另外，如果出现登 ...继续阅读 (12)

Linux中，每个进程有一个pid，类型pid_t，由getpid()取得。Linux下的POSIX线程也有一个id，类型pthread_t，由pthread_self()取得，该id由线程维护，其id空间是各个进程独立的（即不同进程中的线程可能有相同的id）。你可能知道，Linux中的POSIX线程库实现的线程其实也是一个进程（LWP），只是该进程与主进程（启动线程的进程）共享一些资源而已，比如代码段，数据段等。有时候我们可能需要知道线程的真实pid。比如进程P1要向另外一个进程P2中的某个线程发送信号时，既不能使用P2的pid，更不能使用线程的pthread id，而只能使用该线程的真实pid，称为tid。有一个函数gettid()可以得到tid，但glibc并没有实现该函数，只能通过Linux的系统调用syscall来获取。使用syscall得到tid只需一行代码，但为了加深各位看官的印象，简单提供下面场景。有一簇进程，其中一个进程中另外启了一个线程。各进程共享一个数据结构，由shared_ptr指明，其中保存有线程的tid。在各个进程的执行过程中，需要判断线程是否存在，若不存在则（重新）创建。首先，在线程函数的开始，需要将自己的tid保存至共享内存，1 2 3 4 5 6 7 8 9 10#include <sys/syscall.h>#include < ...继续阅读 (11)