framework之项目环境变量和别名

1. 背景

为项目定义环境变量和别名，是个很好的实践：提高效率，屏蔽复杂的命令，降低策划使用自己的一套服务器环境的门槛。

2. 命令

我们的项目环境变量和别名存在名为alias_cmd的文件中，置于项目目录下，操作项目前需要source或“. ”导入变量或别名定义。目前的命令主要有下面几类。

2.1. 检查别名文件的打开方式

别名文件需要source或“. ”导入变量或别名定义，直接“./”执行会报错，防止被错误执行。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SELF_NAME="${BASH_ARGV[0]}"
if [ "$SELF_NAME" == "" ]; then
    SELF_PATH=$0
    if [ ${SELF_PATH:0:1} != "/" ]; then 
        SELF_PATH="$PWD/$SELF_PATH"
    fi
    cat <<END_OF_USAGE
usage:
    敲 ". $SELF_PATH" 回车
    或者加入bashrc：echo ". $SELF_PATH" >> ~/.bashrc
    一些命令会改变目录，用命令"cd -"切回    
    gdbxx 已经设置好参数，可以直接r
END_OF_USAGE
    exit -1
fi

2.2. grep进程

1
2
3
4
5
USER=`whoami`
USER_ID=`id -u`
alias psmy="ps -ef | egrep \"^($USER|$USER_ID)\" | grep "

...

2.3. cd到各种目录

1
2
3
alias cdr="cd $PROJ_BASE"

...

2.4. 启停服务

1
2
3
alias startgs="echo -ne \"\\e]2;game_server\\a\";cd $PROJ_BASE/server/gameserver/UnitTest;./gameservergame_app -c gameserver.lua"
alias stopgs="psmy gameservergame_ap[p] |awk '{print \$2;}' |xargs -n 1 -i kill -10 {}"
...

2.5. profile

1
2
alias profgs="cd $PROJ_BASE/server/gameserver/UnitTest;env CPUPROFILE=./gameservergame_app.prof ./gameservergame_app -c gameserver.lua"
...

2.2. 带参数启动的gdb命令

1
alias gdbgs="cd $PROJ_BASE/server/gameserver/UnitTest;gdb --args ./gameservergame_app -c gameserver.lua"

2.3. gdb attach命令

1
alias agdbgs="export a=\`psmy gameservergame_ap[p] |awk '{print \$2;}' \`; gdb -p \$a;"

3. 注意

别名文件跟随分支，不用分支的别名文件直接改，交由版本工具管理，不要弄多份，不然会混淆。

一个ssh终端对应一个项目分支，不然也容易混淆（可以通过命令改终端名字）。

展开全文 >>

framework-nd之强迫症的Makefile

1. 设计思路

经历的项目里，见过有用autoconf的，但是私有的server，部署环境是确定的，大多都是直接用Makefile。

为什么说是强迫症的呢？主要是最初有这么几个想法：

  • 见到的其他所有Makefile，.o文件和.c/.cpp文件是放在一起的，觉得不美观，想仿VS，放在另外一个文件夹里，如.lib。和VS不同的是，笔者还想在这个目录下建立和源代码一样的目录体系，.o文件放在各自的目录下。这样有什么好处呢，不同的目录相当于不同的命名空间，如果没有目录结构，这部分信息就丢了。如我们的miniserver在不同的目录下，有两个相同名字的misc.cpp，内容是不一样的（一个有用，一个是废的），其Editor的版本是用VS编译的，因为VS是没有保留目录信息的，后编译的文件会覆盖前一个，就造成了一个诡异的结果，有时是ok的，有时链接符号未定义…这个bug让人好找
  • Makefile支持include的语法，另一个想法是将它做成插件化，各层的Makefile只要include了之后，对几个变量进行赋值就ok了（Android的Makefile也是这么干的）。
  • 增量编译

这个Makefile框架后来用于游戏项目，另外加了

  • Debug版本的所有输出文件名加上”_d”，Release版本的所有输出文件加上”_r”，这样将Debug版和Release版的输出隔开，避免链接串文件。

对项目文件的管理，设想是一个顶层目录一个库（如前文的线程组一个目录，网络库一个目录，逻辑层的FSM一个目录…），先编译成静态库或者动态库（动态库问题比较多，我们最后都用静态库了）;每个库带一个UnitTest目录，一边写一边测，最后这个UnitTest就被当成执行文件了。

2. 实现

先看一个目录的例子。

2.1. 一个应用的例子

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
59
60
61
#########################################
#                top dir                #
#########################################
PROJBASE=$(CURDIR)/../../

#########################################
#                target                 #
#########################################
PRE_CMD=echo 'pre compile cmd'
POST_CMD=echo 'post compile cmd on success'
SUBDIR= .
EXCEPT_FILES=  %test.cpp 

#########################################
#      header and lib dependancy        #
#########################################
INC_DIR= -I.  \
	-I/usr/include/mysql \
	-I$(PROJBASE)/lib/include \

DEBUG_STATIC_LIB= \
	$(PROJBASE)/lib/libmysqlclient_r.a \
	$(PROJBASE)/lib/libcommon$(BUILD_SUFFIX).a \
	$(PROJBASE)/lib/libffluajit.a \
	$(PROJBASE)/lib/libtcmalloc_debug.a \
	$(PROJBASE)/lib/libprofiler.a \
	$(PROJBASE)/lib/libunwind.a \
	$(PROJBASE)/lib/libcurl.a \
	$(PROJBASE)/lib/libssl.a \
	$(PROJBASE)/lib/libcrypto.a\
	$(PROJBASE)/lib/libz.a\
	$(PROJBASE)/lib/libcares.a\

RELEASE_STATIC_LIB= \
	$(PROJBASE)/lib/libmysqlclient_r.a \
	$(PROJBASE)/lib/libcommon$(BUILD_SUFFIX).a \
	$(PROJBASE)/lib/libffluajit.a \
	$(PROJBASE)/lib/libtcmalloc.a \
	$(PROJBASE)/lib/libprofiler.a \
	$(PROJBASE)/lib/libunwind.a \
	$(PROJBASE)/lib/libcurl.a \
	$(PROJBASE)/lib/libssl.a \
	$(PROJBASE)/lib/libcrypto.a\
	$(PROJBASE)/lib/libz.a\
	$(PROJBASE)/lib/libcares.a\

SHARED_LIB_DIR=
DEBUG_SHARED_LIB= -pthread -ldl -lrt
RELEASE_SHARED_LIB= -pthread -ldl -lrt

#########################################
#              compiler                 #
#########################################
include $(PROJBASE)/build/makefile.compiler.gcc

#########################################
#              rules                    #
#########################################
include $(PROJBASE)/build/makefile.compile.rules


  • PROJBASE即工程根目录。.lib目录就在根目录下。
  • PRE_CMD/POST_CMD 分别是编译前和编译后执行的命令。
  • SUBDIR 是当前目录下的源文件目录，可包含多个，自动编译.c/.cpp
  • EXCEPT_FILES 是不需要编译的文件列表
  • INC_DIR 头文件查找路径
  • DEBUG_STATIC_LIB/RELEASE_STATIC_LIB 分别是依赖的debug和release版本的静态库。
  • SHARED_LIB_DIR 是动态库查找路径
  • DEBUG_SHARED_LIB/RELEASE_SHARED_LIB 分别是依赖的debug和release版的动态库。
  • makefile.compiler.gcc定义编译器，代码如下，我们warning当error处理，同时忽略了部分warning，-Wl,–eh-frame-hdr是tcmalloc的建议，其他没太多东西，备查。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CC=g++
cc=gcc
AR=ar
RANLIB=ranlib
ARFLAGS=rcs
SHAREDFLAG= -fPIC -shared
DEBUG_FLAGS=-g -DDEBUG -D_FILE_OFFSET_BITS=64
RELEASE_FLAGS=-g -O3 -D_FILE_OFFSET_BITS=64
CFLAGs=-Wall -Werror -fno-strict-aliasing -Wno-deprecated-declarations -Wno-array-bounds $(INC_DIR)
CXXFLAGS=-Wall -Werror -fno-strict-aliasing -Wno-deprecated-declarations -Wno-array-bounds $(INC_DIR) 
LDFLAGS=-Wl,--eh-frame-hdr $(SHARED_LIB_DIR) $(STATIC_LIB) $(SHARED_LIB) 
DEBUG_DIRNAME=Debug
RELEASE_DIRNAME=Release
DEBUG_SUFFIX=_d
RELEASE_SUFFIX=_r
  • makefile.compile.rules 即本文所要讲的工具了。

OK，设计思想就这样，定义变量，其他交给makefile.compile.rules，如下。

2.2. 定义输出

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
#########################################
#          OUT DIR                      #
#########################################
DIR_LIST=$(subst /, \ , $(CURDIR))
MOD_NAME=$(word $(words $(DIR_LIST)), $(DIR_LIST))

DEBUG_BIN_TARGET=$(if $(APPDIR), $(MOD_NAME)$(DEBUG_SUFFIX))
DEBUG_SHARED_TARGET=$(if $(COMPILE_SHARED),lib$(MOD_NAME)$(DEBUG_SUFFIX).so)
DEBUG_STATIC_TARGET=lib$(MOD_NAME)$(DEBUG_SUFFIX).a
DEBUG_TARGET = $(DEBUG_BIN_TARGET) $(DEBUG_SHARED_TARGET) $(DEBUG_STATIC_TARGET)

RELEASE_BIN_TARGET=$(if $(APPDIR), $(MOD_NAME)$(RELEASE_SUFFIX))
RELEASE_SHARED_TARGET=$(if $(COMPILE_SHARED),lib$(MOD_NAME)$(RELEASE_SUFFIX).so)
RELEASE_STATIC_TARGET=lib$(MOD_NAME)$(RELEASE_SUFFIX).a
RELEASE_TARGET = $(RELEASE_BIN_TARGET) $(RELEASE_SHARED_TARGET) $(RELEASE_STATIC_TARGET)

OUTDIR_PREFIX=$(PROJBASE)/.lib
OUTDIR=$(OUTDIR_PREFIX)/$(MOD_NAME)
#ALL_TARGET = $(addprefix $(OUTDIR_PREFIX)/, $(TARGET))

DEBUG_DIR=$(PROJBASE)/$(DEBUG_DIRNAME)
RELEASE_DIR=$(PROJBASE)/$(RELEASE_DIRNAME)
MOD_DEBUG_OUTDIR=$(DEBUG_DIR)/$(MOD_NAME)
MOD_RELEASE_OUTDIR=$(RELEASE_DIR)/$(MOD_NAME)
  • MOD_NAME即最后一层目录
  • DEBUG_SUFFIX/RELEASE_SUFFIX 是前面说的”_d”/“_r”后缀
  • 然后定义了输出的静态库
  • OUTDIR是本模块的输出目录，”.lib”下的目录
  • 后面DEBUG_DIR/RELEASE_DIR是最后正式release的文件，不包含.o文件
  • MOD_DEBUG_OUTDIR/MOD_RELEASE_OUTDIR是本模块的release文件。

2.2. 定义临时输出文件（.o文件)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#########################################
#               OBJECTS                 #
#########################################
CFILES=$(filter-out $(EXCEPT_FILES), \
	$(foreach DIR, $(SUBDIR), $(wildcard $(DIR)/*.c)) )
CPPFILES=$(filter-out $(EXCEPT_FILES), \
	$(foreach DIR, $(SUBDIR), $(wildcard $(DIR)/*.cpp)) \
        $(TOLUACPP) )
CCFILES=$(filter-out $(EXCEPT_FILES), \
	$(foreach DIR, $(SUBDIR), $(wildcard $(DIR)/*.cc)) )
TMP_OBJECTS=$(patsubst %.cpp, %.o, $(CPPFILES)) \
	$(patsubst %.cc, %.o, $(CCFILES)) \
           $(patsubst %.c, %.o, $(CFILES)) 
OUTSUBDIR=$(addprefix $(OUTDIR)/, $(SUBDIR) \
    $(if $(TOLUACPP), LuaObject))
    
TMP_PATH_OBJECTS=$(addprefix $(OUTDIR)/, $(TMP_OBJECTS))
DEBUG_OBJECTS=$(patsubst %.o, %$(DEBUG_SUFFIX).o, $(TMP_PATH_OBJECTS))
RELEASE_OBJECTS=$(patsubst %.o, %$(RELEASE_SUFFIX).o, $(TMP_PATH_OBJECTS))
  • CFILES/CPPFILES/CCFILES 是所有源代码文件的相对路径
  • TMP_OBJECTS 是所有.o文件的相对路径
  • OUTSUBDIR 是需要新建的.lib目录文件
  • TMP_PATH_OBJECTS 是所有.o文件的绝对路径
  • DEBUG_OBJECTS/RELEASE_OBJECTS 是给.o文件加上”_d”/“_r”后缀

2.3. UnitTest的相关文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#########################################
#        Test    Target                 #
#########################################
TEST_DIR=UnitTest
TEST_CPP_FILES=$(foreach DIR, $(TEST_DIR), $(wildcard $(DIR)/*.cpp))
TEST_OUT_SUBDIR=$(addprefix $(OUTDIR)/, $(TEST_DIR))

DEBUG_TMP_TEST_OBJECTS=$(patsubst %.cpp, %$(DEBUG_SUFFIX).o, $(TEST_CPP_FILES))
DEBUG_TEST_OBJECTS=$(addprefix $(OUTDIR)/, $(DEBUG_TMP_TEST_OBJECTS))
DEBUG_TEST_TARGET=$(basename $(notdir $(DEBUG_TEST_OBJECTS)))

RELEASE_TMP_TEST_OBJECTS=$(patsubst %.cpp, %$(RELEASE_SUFFIX).o, $(TEST_CPP_FILES))
RELEASE_TEST_OBJECTS=$(addprefix $(OUTDIR)/, $(RELEASE_TMP_TEST_OBJECTS))
RELEASE_TEST_TARGET=$(basename $(notdir $(RELEASE_TEST_OBJECTS)))

TEST_OUTDIR=$(OUTDIR_PREFIX)/test
TEST_FILE=$(foreach DIR, $(TEST_DIR), $(wildcard $(DIR)/*.lua) \
                                     $(wildcard $(DIR)/*.xml) \
                                     $(wildcard $(DIR)/*.pcap))
TEST_OUT_FILE=$(addprefix $(TEST_OUTDIR)/, $(notdir $(TEST_FILE)))

和前面类似

2.4. 定义增量编译所需要的依赖文件

1
2
3
4
5
6
7
#########################################
#               Depend                  #
#########################################
DEPENDFILES=$(patsubst %.o, %.d, $(TMP_PATH_OBJECTS))
DEPENDTARGET=$(patsubst %.d, %.d.tmp, $(DEPENDFILES))
TESTDEPENDFILES=$(patsubst %.o, %.d, $(TEST_OBJECTS))
TESTDEPENDTARGET=$(patsubst %.d, %.d.tmp, $(TESTDEPENDFILES))

我们会在.d文件里临时存放.cpp所依赖的头文件

2.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
26
27
28
29
30
test: CFLAGS+=$(DEBUG_FLAGS)
test: CXXFLAGS+=$(DEBUG_FLAGS)
test: MOD_OUTDIR=$(MOD_DEBUG_OUTDIR)
test: DEST_OUTDIR=$(DEBUG_DIR)
test: SHARED_LIB+=$(DEBUG_SHARED_LIB)
test: STATIC_LIB+=$(DEBUG_STATIC_LIB)
test: BUILD_SUFFIX=$(DEBUG_SUFFIX)
test: prepare $(DEBUG_TEST_TARGET)
	@if [ "" != "$(POST_CMD)" ]; then \
		$(POST_CMD); \
	fi;

rtest: CFLAGS+=$(RELEASE_FLAGS)
rtest: CXXFLAGS+=$(RELEASE_FLAGS)
rtest: MOD_OUTDIR=$(MOD_RELEASE_OUTDIR)
rtest: DEST_OUTDIR=$(RELEASE_DIR)
rtest: SHARED_LIB+=$(RELEASE_SHARED_LIB)
rtest: STATIC_LIB+=$(RELEASE_STATIC_LIB)
rtest: BUILD_SUFFIX=$(RELEASE_SUFFIX)
rtest: prepare  $(RELEASE_TEST_TARGET)
	@if [ "" != "$(POST_CMD)" ]; then \
		$(POST_CMD); \
	fi;

prepare:
	@if [ "" != "$(PRE_CMD)" ]; then \
		$(PRE_CMD); \
	fi;

不同的target应用不同的变量，执行pre/post相关操作。debug版本是make test，release版本是make rtest。

2.6. 下层规则

1
2
3
4
5
$(DEBUG_TEST_TARGET): $(MOD_OUTDIR) $(AUTOTARGET) $(DEBUG_TARGET) testdepend $(TEST_OUT_SUBDIR) $(DEBUG_TEST_OBJECTS) $(TEST_OUTDIR) $(TEST_OUT_FILE) $(SYMBOL_OUTDIR) deploy_common
	$(call build_test_exe,$@, $(DEBUG_OBJECTS)) # no blank before $@

$(RELEASE_TEST_TARGET): $(MOD_OUTDIR) $(AUTOTARGET) $(RELEASE_TARGET) testdepend $(TEST_OUT_SUBDIR) $(RELEASE_TEST_OBJECTS) $(TEST_OUTDIR) $(TEST_OUT_FILE) $(SYMBOL_OUTDIR) deploy_common
	$(call build_test_exe,$@, $(RELEASE_OBJECTS)) # no blank before $@

2.6.1. 新建各种目录

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
$(MOD_OUTDIR):
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(DEBUG_DIR):
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(RELEASE_DIR):
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(MOD_DEBUG_OUTDIR):$(DEBUG_DIR)
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(MOD_RELEASE_OUTDIR): $(RELEASE_DIR)
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(OUTDIR):$(OUTDIR_PREFIX)
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(OUTDIR_PREFIX):
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(TEST_OUTDIR):
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(TEST_OUT_SUBDIR):
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(OUTSUBDIR):
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

$(SYMBOL_OUTDIR):$(OUTDIR_PREFIX)
	@if [ ! -d $@ ]; then mkdir -p $@; fi;

2.6.2. 增量编译.o

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
-include $(DEPENDFILES) $(TESTDEPENDFILES)
$(OUTDIR)/%.d.tmp:%.cc
	@echo "building dependancy for $<..."
	@set -e; rm -f $@ $(OUTDIR)/$*.d; \
	($(CC) $(CXXFLAGS) -MM -c $< > $@ || rm -f $@) &&  \
	sed 's,\(.*\)\.o[ :]*,$(OUTDIR)/$*.o $@: ,g' <$@ >$(OUTDIR)/$*.d; 

$(OUTDIR)/%.d.tmp:%.cpp
	@echo "building dependancy for $<..."
	@set -e; rm -f $@ $(OUTDIR)/$*.d; \
	($(CC) $(CXXFLAGS) -MM -c $< > $@ || rm -f $@) &&  \
	sed 's,\(.*\)\.o[ :]*,$(OUTDIR)/$*.o $@: ,g' <$@ >$(OUTDIR)/$*.d; 

$(OUTDIR)/%.d.tmp:%.c
	@echo "building dependancy for $<..."
	@set -e; rm -f $@ $(OUTDIR)/$*.d; \
	($(cc) $(CXXFLAGS) -MM -c $< > $@ || rm -f $@) &&  \
	sed 's,\(.*\)\.o[ :]*,$(OUTDIR)/$*.o $@: ,g' <$@ >$(OUTDIR)/$*.d; 

$(OUTDIR)/%$(DEBUG_SUFFIX).o:%.cc $(OUTDIR)/%.d.tmp 
	$(CC) $(CXXFLAGS) -c $< -o $@

$(OUTDIR)/%$(DEBUG_SUFFIX).o:%.cpp $(OUTDIR)/%.d.tmp
	$(CC) $(CXXFLAGS) -c $< -o $@

$(OUTDIR)/%$(DEBUG_SUFFIX).o:%.c $(OUTDIR)/%.d.tmp
	$(cc) $(CXXFLAGS) -c $< -o $@

$(OUTDIR)/%$(RELEASE_SUFFIX).o:%.cc $(OUTDIR)/%.d.tmp
	$(CC) $(CXXFLAGS) -c $< -o $@

$(OUTDIR)/%$(RELEASE_SUFFIX).o:%.cpp $(OUTDIR)/%.d.tmp
	$(CC) $(CXXFLAGS) -c $< -o $@

$(OUTDIR)/%$(RELEASE_SUFFIX).o:%.c $(OUTDIR)/%.d.tmp
	$(cc) $(CXXFLAGS) -c $< -o $@

.o文件依赖.d.tmp和源文件，%d.tmp依赖与源文件，调用gcc生成源文件的依赖头文件，然后将这些文件include进来。这样，依赖的头文件或源文件有改动，都会再重新编译。

2.7. 抽出来的函数

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
#########################################
#               Function                #
#########################################
# $(1): static_target
# $(2): objects
define build_static_lib
	$(AR) $(ARFLAGS) $(OUTDIR_PREFIX)/$(1) $(2)
	@echo " $(2) " > $(OUTDIR_PREFIX)/$(MOD_NAME).objectlist
endef

# $(1): shared_target
# $(2): objects
define build_shared_lib
	$(CC) $(SHAREDFLAG) -o $(OUTDIR_PREFIX)/$(1) $(2)
	@echo " $(2) " > $(OUTDIR_PREFIX)/$(MOD_NAME).objectlist
endef

# $(1): test_target
# $(2): objects
#	@$(SYMBOL_DUMPPER) $(TEST_OUTDIR)/$(MOD_NAME)$@ > $(SYMBOL_OUTDIR)/$(MOD_NAME)$@.sym
#	@RT_SYMBOL_DIR=$(SYMBOL_OUTDIR)/`head -n1 $(SYMBOL_OUTDIR)/$(MOD_NAME)$@.sym | awk '{print $$5;}'`/`head -n1 $(SYMBOL_OUTDIR)/$(MOD_NAME)$@.sym | awk '{print $$4;}'`; \
#	if [ ! -d "$$RT_SYMBOL_DIR" ]; then mkdir -p "$$RT_SYMBOL_DIR"; fi; \
#	cp $(SYMBOL_OUTDIR)/$(MOD_NAME)$@.sym "$$RT_SYMBOL_DIR"/; \
#	rm $(SYMBOL_OUTDIR)/$(MOD_NAME)$@.sym;
define build_test_exe 
	$(CC) $(CXXFLAGS) $(OUTDIR)/$(TEST_DIR)/$(1).o $(2) $(LDFLAGS) -o $(TEST_OUTDIR)/$(MOD_NAME)$(1)
	@mkdir -p $(MOD_OUTDIR) 
	@cp $(TEST_OUTDIR)/$(MOD_NAME)$(1) $(MOD_OUTDIR)/
	@cp $(TEST_DIR)/*.svn $(MOD_OUTDIR)/
	@cd UnitTest/ \
        && find script/  -name "*.lua" |xargs -n 1 -i dirname {} |sort |uniq | xargs -n 1 -i mkdir -p $(MOD_OUTDIR)/{} \
	    && find script/  -name "*.lua" |sed -e 's/\.lua//g' |xargs -n 1 -i bash -c 'LUA_PATH=$(PROJBASE)/lib/bin/?.lua $(PROJBASE)/lib/bin/luac -O3 -bg {}.lua $(MOD_OUTDIR)/{}.lc || exit 255' 
	@cd $(MOD_OUTDIR)/ \
        && ln -sf ../resource . \
        && ln -sf $(MOD_NAME)$(1) `echo "$(MOD_NAME)$(1)" | sed -e 's/$(DEBUG_SUFFIX)\|$(RELEASE_SUFFIX)$$//'`  
	@cd $(TEST_OUTDIR)/ \
        && ln -sf $(MOD_NAME)$(1) `echo "$(MOD_NAME)$(1)" | sed -e 's/$(DEBUG_SUFFIX)\|$(RELEASE_SUFFIX)$$//'`  
	@cd $(MOD_OUTDIR)/script \
        && ln -sf ../../luacommon . 
endef

2.8. 顶层的Makefile

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
59
#########################################
#                top dir                #
#########################################
PROJBASE=$(CURDIR)
RELEASE_DIR=Debug Release

#########################################
#                target                 #
#########################################
SUBDIR= sceneobj\
	server/bfserver  \
	server/dbserver  \
	server/gameserver  \
	server/loginserver  \
	server/robotclient \
	server/logserver \

#########################################
#            rules                      #
#########################################
all: msg $(SUBDIR)
	@for DIR in $(SUBDIR);  \
	do                     \
		make -C $$DIR || exit -1; \
	done                  

debug: all

test: debug $(SUBDIR) $(OUTDIR)
	@for DIR in $(SUBDIR);  \
	do                     \
		make test -C $$DIR || exit -1; \
	done                  

rtest: release $(SUBDIR) $(OUTDIR)
	@for DIR in $(SUBDIR);  \
	do                     \
		make rtest -C $$DIR || exit -1; \
	done                  

clean: $(SUBDIR)
	@rm -rf $(RELEASE_DIR)
	@for DIR in $(SUBDIR);  \
	do                     \
		make clean -C $$DIR || exit -1;  \
	done                  

release: msg
	@for DIR in $(SUBDIR);  \
	do                     \
		make release -C $$DIR || exit -1; \
	done                  

msg:
	lua $(PROJBASE)/server/luacommon/gen_msg_header.lua $(shell pwd)


.PHONY:all test rtest clean release

展开全文 >>

framework-nd之singleton模板

1. 实现

无侵入设计，把任意类变成singleton：

Singleton.hpp

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
template<typename DataType, int instanceId = 0>
class Singleton 
{
public: 
    static DataType* instance()
    {
        if (NULL == dataHolderM.get())
        {
            boost::lock_guard<boost::mutex> lock(dbLockMutexM);
            if (NULL == dataHolderM.get())
            {
                dataHolderM.reset(new DataType);
            }
        }
        return dataHolderM.get();

    }
private:
    Singleton(){};
    ~Singleton(){};

    static std::auto_ptr<DataType> dataHolderM;
    static boost::mutex dbLockMutexM;
};

template<typename DataType, int instanceId>
std::auto_ptr<DataType> Singleton<DataType, instanceId>::dataHolderM;

template<typename DataType, int instanceId>
boost::mutex Singleton<DataType, instanceId>::dbLockMutexM;

因为是模板，static变量的定义可放头文件，c++编译器对每个实体类的static变量仅定义一次。

如果需要多个实例，可以为instanceId赋不同的值（如下），否则忽略。

1
2
3
4
5
6
7
8
9
10
class A{};

typedef DesignPattern::Singleton<A, 0> TheA;
typedef DesignPattern::Singleton<A, 1> AnotherA;

int main()
{
    assert(TheA::instance() != AnotherA::instance());
    return 0;
}

2. 使用注意

后来碰到的问题，析构顺序需要控制，当时是通过调整链接顺序解决。现在想想，更好的是at_exit，main前先全声明一遍，逆序析构。

展开全文 >>

framework-nd之读写线程隔离的FIFO队列

1. 设计

1.1. 想法

设计框架(背景见链接)的时候，经常会碰到生产者消费者模型，当时就想整型以机器字长对齐，其赋值和读取都是原子的。举个例子 

1
2
size_t i = 0; 
i = 0xFFFF;

在机器字长对齐的情况下，任何时候，a要么是0，要么是0xFFFF，不会出现0xFF00。（如果是pack（1），上面就不成立了）

因此就有个很天然的想法，如果生产者和消费者各一个，分属不同线程，生产者只修改写偏移量，消费者只改读偏移量，两个偏移量设为volatile保证其只能从内存读取(volatile不能保证线程安全，这里的安全是通过内存总线保证偏移量的完整性实现的)，是不是能实现一个FIFO的循环队列，不加锁的情况下也能保证队列内数据的完整性。

1.2. 读写分析

设想一下，如果生产者写偏移量不更新，消费者首先判断当前无数据可读；
w=r

生产者将数据写入，然后才更新写偏移量，整个过程只有写偏移量修改修改后，消费者才能开始读。
w

1.3. 偏移量的处理

以上写/读流程都工作得很好，直到写偏移量>buffer大小
wl
因为写之前要判断剩下多少空间可写

1
2
size_t usedSize = writeIndexM - readIndexM;
size_t leftSize = sizeM - usedSize;

如果将writeIndexM限制于[0, sizeM)，因为readIndexM只能由消费者改，那么下次写，这条公式就不对了。

怎么处理呢？与其做复杂的判断，不如不限偏移量的范围，就让writeIndexM和readIndexM只增不减，即使是溢出，因为sizeM远小于量偏移量的取值范围，上面的公式还是成立的。

这样子，带来另外一个问题，如何将writeIndexM映射回buffer的偏移量呢？很简单，对sizeM取余就好。这样对sizeM会有限制，比如32bit，因为有溢出的问题，推导要求 (0xFFFFFFFF + 1) % sizeM = 0 % sizeM = 0，即

fomula

也就是说sizeM必须是2的倍数

至此，这个循环的buffer就成型了，一个线程读一个线程写，不用加锁，互不干扰。如果多个生产者，需要在生产者侧加锁。消费者类似。

2. 实现

源代码，32位及以上适用：

3. 后记

当时查过，size_t的赋值在机器字长对齐的情况下，部分平台可能会由多条指令实现的，这种平台(网上也没说是什么平台，估计比较小众)不适用。根据笔者的测试，x86/x64是ok的，arm的默认thumb指令集也ok。请测试使用。

展开全文 >>

framework-nd之网络模型

1. 背景

框架背景见上篇。

网络框架的设计参考了python的异步框架twisted。

笔者对同步和异步性能的认识源于还在爱立信的两个项目，第一个项目是同步的，2-3k的tps，性能压不上去，客户端您随便加压力，我服务端就不理你，就这种；第二个项目是异步的，1w的tps，实验室环境在瑞典，一直没机会玩玩。但笔者因为是研发中心支持，在一线人员配合下能直接登录上生成环境，最惨烈的一次是阿三的服务器，就看着内存一直在涨，5分钟一挂…您没听错，就是5分钟一挂，提单的严重级别是中级，要放国内早爆了…除了升级扩容别无他法。当时就感叹，异步没有压不爆的机器。

鉴于此，笔者当时看了挺多异步的设计，twisted是印象最深的一个。接着用python写一个自己的python测试框架pythontest, 但一直都没派上用场。framework-nd的网络模型其实就是pythontest的c++版。但笔者的python仅限于东拼西凑，答不出所以然。

2. 设计

写网络框架的人，应该都看过《unix网络编程》，也知道平台差异性。笔者选用libevent1（2的设计比较复杂，没用）去封装平台差异，socket的读写按边缘触发处理。

class_model

  • Reactor 独占一线程，跑event_base_dispatch。提供接口，监听socket的事件。
  • TcpServer 新建监听端口，将新连接和上层处理逻辑处理初始化成SocketConnection。
  • SocketConnection 维护已连接的socket，负责异步读写socket，读写各维护一队列。并将网络事件上报给Protocol。
  • IProtocol 负责TcpServer的配置和处理网络事件。其主要从网络流（SocketConnection的读缓存）中解析出消息体，或将消息体写入SocketConnection的写缓存。
  • TcpClient负责connect之前的逻辑，connect之后生成SocketConnection，逻辑交由SocketConnection维护，连接断开后负责重连。TcpClient设想支持多个连接，但是没有这样的需求就没实现。
    以上类除了Reactor，其他类初始化参数均包含一线程组引用，按调试需要，可以用不同的线程组初始化，也可以用相同的线程组初始化。通知事件跑在原线程，事件的处理跑在线程组socket fd对应线程。

恩， 好像完了？大的部分好像真的完了，但是细节都在代码里。例如做了流控，即接收缓存在高水位，则不再从socket读取，滑动窗口协议会导致客户端不再发送，知道接收队列被处理至正常水平，防止服务器被输入压垮了。

另外，这玩意还是很考验多线程调试技巧的。

3. 举个例子吧

EchoServer是这么启的，telnetServer是管理端口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Processor::BoostProcessor processor("NetProcessor", 4);
processor.start();
Net::Reactor::Reactor reactor;
Net::Protocol::EchoProtocol echoProtocol(&reactor, &processor);
Net::Protocol::TelnetProtocol telnetProtocol(Processor::BoostProcessor::manInstance());
Net::Server::TcpServer server(&echoProtocol, &reactor, &processor);
Net::Server::TcpServer telnetServer(&telnetProtocol, &reactor, &processor);
server.start();
telnetServer.start();
reactor.start();

boost::unique_lock<boost::mutex> lock(closedMutexM);
while(!closed)
{
    closedCondM.wait(lock);
}

processor.stop();
reactor.stop();
LOG_DEBUG("EchoServer stopped.");

4. 后记

putty-nd同步session数据到Google Drive，需要启一HttpServer配合Google账号的验证，对这套框架略有修改。加力之后代码段增加得不多，还是很小巧的。

展开全文 >>

framework-nd之线程模型

1. 背景

笔者出道于爱立信，电信行业，回想这么多年技术或管理上所用的技巧，思想多源于斯，深有感触。在爱立信还是有些狗屎运的，曾于项目青黄不接时独立维护一个AAAServer，熟悉了内存分配器，把该server的内存按得纹丝不动；然后又在一个全球化的网关产品中做PLM，能纵览其异步io+任务式线程组+javascript的设计。但项目中接触到的框架都是现成的，临渊羡鱼不如退而结网，自己也在开始将认识写成代码，即framework-nd。只是没有需求，怎知其可堪一用？

机会还是来了，即我的第二份工作（加薪30%，如果各种福利一起算，实际只加了几百，如果不是因为这是个机会，估计留不下来，从大平台跳出来，请慎重），当时是要做信令和HTTP流量分析平台，一组人负责解析信令，我一人负责HTTP流量解析（当时https用得不多，不然就歇菜了），信令组需要记录的关键字段发给我，我将其和同时段相应的HTTP的请求/响应的关键字段汇总成一条话单，写文件，待后续分析。然后这个框架就用上了，解决了无数的问题后，在惠州移动上线了，日处理数据约1.5TB/日（我们用TAP设备抓了一天的包，1.5TB，内部拿这1.5T文件测试，千兆网卡带宽压到80%～90%之间，cpu和内存的相关数据时间太久就不记得）。第二次上线信令组也用了这套线程框架。

后来这个框架经过适当的改造，应用于我的工具putty-nd中(zmodem和同步Google Drive的本地服务器)。

2. 设计思路

其实大家都知道，要使系统CPU达到最大的利用率，全局活跃线程数应等于逻辑CPU个数，这样CPU没有切换的开销，负载达到CPU个数，刚好吃饱。

这是条基本规则，现实中会有些变化。

  • CPU个数有限，如何让有限的线程执行各种不同的任务。
  • 纯CPU计算可以让CPU忙起来，但是同步的调用，如Oracle的访问接口，或者需要同步的系统调用（日志）会让线程挂起，导致CPU释放，如果没其他活跃的线程，CPU就闲下来了。
  • 锁/同步都会让线程挂起，如何最大限度地减少这种可能性。

结合之前的经验，做了下面的设计。

  • 针对第一个问题，用命令模式，将不同的处理函数和数据用boost::bind封装成boost::function<void (*)()>，提交各自线程的处理队列，线程仅需处理这个队列。这样一个线程即可以进行多任务处理。
  • 第二个问题，线程分组。纯CPU计算的任务和会让CPU挂起的任务分属不同的组（按需求可以再细分），组内线程地位平等，数量可调。提交处理任务是向线程组提交，提交接口包含一session_id，线程组按此session_id分配到线程处理（取余），这样线程组可以保证同一id的任务会按顺序先后在同一线程处理。
  • 第三个问题，创造单线程环境。按逻辑，需要先后处理的各个任务可由逻辑层归为一个session，并分配id，同一session_id的任务按session_id像线程组提交，线程组保证这个会话的任务在同一线程先后处理。会话可能有多个在多个线程触发事件源，但其向线程组提交后在线程的任务队列中串行化，其处理任务不用加锁。
  • 对队列加锁，尽量不对一大块逻辑操作加锁。如任务队列需要加锁，session的自增id需要加锁。存储session的集合可以定义和处理线程数内相同的个数，在线程启动前初始化好，分别访问避免加锁。也可以用Thread Local Storage，但这种设计有点侵入性，笔者未采用。

在调试中发现session的任务可能会在错误的线程处理，因此加入了一些防错的校验。

在后来的调优中，发现如果各个线程共享系统的定时器队列，输入在100Mbit/s时达到处理的瓶颈。因为会话需要同步各个输入，用到了大量的定时器，因此改在线程上用最小堆实现了会话的定时器管理。因为同一会话的处理都在同一线程，避免了定时器任务的加锁，顺利跨过这个坎，使输入达到网卡带宽的80%～90%时，仍能稳定处理。

实践发现的一些冗余的设计：对队列设计了池子，但对tcmalloc这种现代分配器，对比发现完全看不出有任何优化。也就是说，无初始化负担仅是内存池子的设计，可以完全交给内存分配器。

3. 实现

有设计的蓝图，实现就不难了，链接。

主要有两个类，Boost的版本，实现还有Pthread的版本，不知道丢哪去了，简单改几个东西， 不麻烦。

  • BoostProcessor，线程组，组内线程接口不对外开放，只能用一带session id的接口向线程组提交任务。
  • BoostWorker，线程的处理函数，处理任务队列和定时器队列。
  • ProcessorSensor，监控线程任务队列数量，如果处理不过来，任务数量会堆积，内存就上去了。

3.1 外部接口

对外提供的接口有三类。

  • BoostProcessor（线程组）构造函数和析构函数
  • 线程启停
  • 提交任务和Timer

3.1.1. BoostProcessor构造函数和析构函数。

1
2
3
BoostProcessor(const unsigned theThreadCount);
BoostProcessor(const std::string& theName, const unsigned theThreadCount);
~BoostProcessor();

构造函数除了数量，还有一个带名字的。方便知道是哪组线程发生了堆积。其实建议用pthread_setname_np为每个线程都设个名字，这样用Top命令就能看到各个线程的cpu负载情况。

3.1.2. start/stop线程

1
2
3
void start();
void waitStop();
void stop();

3.1.3. 提交任务和Timer

1
2
3
4
5
6
7
8
9
10
11
12
struct event* addLocalTimer(
                const unsigned long long theId, 
				const struct timeval& theInterval, 
				event_callback_fn theCallback,
				void* theArg);
inline void cancelLocalTimer(
        const unsigned long long theId, 
        struct event*& theEvent);

int process(
        const unsigned long long theId, 
        void (*theFunc)());;

Timer放在线程上的原因说过了。
看了一下，最新代码的任务还是带了池子的版本，用了大量的模板，导致执行文件过大，性能上没提升，这是一个不太成功的实践。直接用boost::function简化就行了。

3.2. 线程的实现

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
void BoostWorker::run()
{
    initThreadAttr();
    IJob* job;
    while (!isToStopM)
    {
        //handle Job
        if (0 < bufferJobQueueM.getn((char*)&job, sizeof(IJob*)))
        {
            (*job)();
            job->returnToPool();
            job = NULL;
        }

        //handle timer
        handleLocalTimer();

		if (!bufferJobQueueM.empty())
		{
			continue;
		}
        else if (!isToStopM && bufferJobQueueM.empty() && !min_heap_empty(&timerHeapM))
        {
            boost::unique_lock<boost::mutex> queueLock(queueMutexM);
            queueCondM.timed_wait(queueLock, 
                    boost::posix_time::from_time_t(timeNowM.tv_sec) 
                        + boost::posix_time::microseconds(timeNowM.tv_usec + 500));
        }
        else
        {
            boost::unique_lock<boost::mutex> queueLock(queueMutexM);
            while (!isToStopM && bufferJobQueueM.empty() && min_heap_empty(&timerHeapM))
            {
                queueCondM.wait(queueLock); 
            }
        }
    }
}

bufferJobQueueM是读写分离的一个数据结构，因为读取只有一个线程，所以没有锁（改天开篇讲）。

定时器队列用的是libevent的最小堆，小巧，提供了删除的接口。

处理完任务后，如果还有任务要处理，则继续处理，如果还有定时时间，time_wait 500微秒（0.5ms，定时器精度就是这个了），否则直接wait。只要有wait，CPU就被释放了，要么timeout切回来，要么新任务有signal唤醒。有人说线程的切换至少要耗时10ms，笔者有印象这应该是出自某本经典的书，说内核的时间片算法最小单位大约10ms。后来再查了一下，这时间片算法单位应该是和频率有关，10ms应该是书作者写书时的数据，算算下应该是上世纪的事情了。

其他就不贴了。代码都在github上。

4. 后记

在游戏行业的时候，因为帧循环是单线程处理的，曾有想法引入线程组，按场景id分线程去处理。当时最大的问题是32bit程序内存受限，n个线程n个lua vm，配置表得n份，太占内存。因为够用，程序人少事多，晃着晃着就过去了。

展开全文 >>

gdb调试Android动态库脚本

1. 背景

  • 为什么会弄这玩意？因为要弄这个热更工具，gdb是绕不过的坎。为什么要弄这个工具，因为我们一直以来客户端世界里都没有lua（Miniserver的不算，那就是跑在客户端的服务器，通过网络层和客户端通信），用ulua之类的大家都得学，多个东西多个鬼，能少则少。
  • 理论上，ndk提供了gdb的封装脚本ndk-gdb，理论上能方便无缝地像在linux server一样远程连gdbserver。但因为gdb所在环境和手机环境的多样性，这个脚本基本跑不通。而且这个脚本不稳定，也在随版本号升级，你可以想象把脚本过一遍，还原出该设的环境变量，一升级，日了狗了，又不行了，还得再过一遍。×#&%￥！，还是把里面的东西扒出来，直接用gdb+gdbserver。但即使是直接用gdb+gdbserver，各个命令在不同环境的表现还是有差异，例如原来能用的adb shell的后台命令更新后就一直占着前台。

2. 调试

以下脚本均为bash脚本，在git bash下执行。gdb调试android的动态库，本质和gdb远程调试Linux程序一样：远端启动gdbserver attach上要调试的应用，同时开放监听端口，然后gdb远程连上去调试。所以其涉及远端（Android）和本机两个系统。

2.1. 准备环境变量

1
2
3
4
5
export PACKAGE_NAME=com.test.test
export NDK=/d/android-ndk-r13b/
export GDBSERVER_BIN=$NDK/prebuilt/android-x86/gdbserver/gdbserver
export GDBC=$NDK/prebuilt/windows-x86_64/bin/gdb.exe
export START_ACTIVITY=$PACKAGE_NAME/$PACKAGE_NAME.UnityPlayerActivity

就这几个，因人而异，自己改，都很简单，不多做解释了，下面的命令会用到。
我用的是模拟器，规避权限问题，所以用的是x86版本的。

2.2. 准备远端环境

用Debug版本的动态库构建App，安装App，App本身是不是debug版本无所谓（App的这个debug版本是给java调试用的，如果是在没有root的真机上，需要开App的Debug，用run-as切到app对应userid，才能attach）。其实用Release版本的动态库也可以调，只是所有调试信息都没了，只能用public的符号或绝对地址下断点，想看参数得直接用栈指针，像下面这样。Ok，这么说，读者应该知道怎么灵活选择了，你想调的那个库是Debug版就行了。

1
2
3
4
5
6
7
b __android_log_print
commands
silent
printf "string:%s\n", *(char**)($esp+12)
bt
cont
end

2.3. 准备本机环境

  • 得保证能连上模拟器，有adb。
  • 本机环境我用的是Windows + git bash，如果你用其他环境，既然你都用了，我相信你能处理好。
  • 建个空目录，在里面启动git bash，执行以下脚本，而且每次App内动态库有变化，都要执行一次。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 把端口映射打开，adb负责把本机的5039端口，映射到远端Android的5039端口
adb forward tcp:5039 tcp:5039 

#把远端Android的动态库取回本地，因为gdb只能从本地加载符号
#注意路径前无/，不然读者可以试试，很讨厌的
adb pull system/bin/app_process
adb pull system/bin/linker
adb pull system/lib/libc.so
adb pull data/data/$PACKAGE_NAME/lib/lib*.so

# gdb.setup是gdb启动的初始化脚本，省得每次gdb再敲一堆命令
# 脚本里忽略两个中断信号，设置so符号查找路径为本目录，然后连接远程的gdbserver
cat >gdb.setup <<END_OF_GDB
handle SIGPWR nostop
handle SIGXCPU nostop
set solib-search-path .

target remote 127.0.0.1:5039
END_OF_GDB

echo "install gdbserver ..."
copy $GDBSERVER_BIN .
adb push  gdbserver  data/local/tmp/gdbserver
adb shell chmod 777 data/local/tmp/gdbserver

2.4. 先封一些函数，方便使用

  • 启动app前，上次调试环境可能还在，下面是清理的gdbserver的函数
1
2
3
4
5
6
7
function kill_gdbserver(){
    GDBSERVER_PID=`adb shell "ps |grep gdbserver" |awk '{print $2;}'`
    if [ "$GDBSERVER_PID" != "" ]; then
        echo "kill pre gdb server process id:$GDBSERVER_PID"
        adb shell kill -9 $GDBSERVER_PID
    fi
}
  • 启动app。启动前清理可能的gdbserver和可能的残留app，启动命令自己按需修改
1
2
3
4
5
6
7
8
9
10
11
12
function start_app(){
    kill_gdbserver
    APP_PID=`adb shell "ps | grep -v ' Z ' |grep $PACKAGE_NAME" | awk '{print $2;}'`
    if [ "$APP_PID" != "" ]; then
        echo "kill pre $PACKAGE_NAME process id:$APP_PID"
        adb shell kill -9 $APP_PID
    fi
    
    adb shell am start -W -n $START_ACTIVITY
    APP_PID=`adb shell "ps | grep -v ' Z ' |grep $PACKAGE_NAME" | awk '{print $2;}'`
    echo "app process id:$APP_PID"
}
  • 计算各个库的代码段加载地址，因为gdb只能从本地环境加载符号。理论上每次启动，都需要计算一次，但是只要App没变化，动态库在App的内存空间中的地址不变，所以，在App第一次启动的时候做一次就行。计算后会加载库的命令给准备好，追加到gdb.setup中。
1
2
3
4
5
6
7
8
9
function map_app(){
    echo "mapping addr.."
    APP_PID=`adb shell "ps | grep -v ' Z ' |grep $PACKAGE_NAME" | awk '{print $2;}'`
    adb shell cat /proc/$APP_PID/maps > maps
    sed -i -e '/add-symbol-file/d' gdb.setup
    ls lib*.so linker |xargs -n 1 -i bash -c "printf 'add-symbol-file {} (0x' && (grep {} maps | grep 'r-xp' | sed -e 's/-.*$//' | tr -d '\r\n')&& printf '+0x' && (readelf -S {}|grep ' .text ' | sed -e 's/^.*PROGBITS\s*//' -e 's/\s.*$//' |tr -d '\r\n') && echo ')'" | sed -e 's/^\(.*\)0x+/#not fould in maps ->\10x0+/' >>gdb.setup
    
    cat gdb.setup|grep add-symbol-file
}
  • 在远端启动gdbserver，attach app
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
function attach_app(){
    echo "killing launched gdbserver if any..."
    kill_gdbserver
    
    echo "starting gdbserver attaching $PACKAGE_NAME..."
    APP_PID=`adb shell "ps | grep -v ' Z ' |grep $PACKAGE_NAME" | awk '{print $2;}'`
    adb shell "data/local/tmp/gdbserver --attach :5039 $APP_PID &" 
    
    echo "data/local/tmp/gdbserver --attach :5039 $APP_PID &"
    #sleep 1
    
    #下面的注释掉了，因为升了版本后，跑到这就挂起了，下面就跑不到了
    #笔者只能另开中断跑下面的命令，就注释掉了
    #echo "running gdb..."
    #$GDBC -x ./gdb.setup 
}

2.5. 调

建议开三个终端（git bash），全都定义好变量和封装的函数。
一个跑

1
start_app

一个接着跑

1
attach_app

最后一个跑

1
2
map_app #这条命令比较慢，仅第一次启动的时候跑就好了
$GDBC -x ./gdb.setup

然后，读者就可以放飞自我了。

展开全文 >>

服务器x64升级之libunwind内存泄漏

1. 背景

关于为什么需要做x64升级的原因参见上篇。
这里分享的是升级之后发生的一次诡异的内存泄漏。

2. 问题表现

  • 刷怪之后，内存随时间明显上涨，RES大概2MB/5s，但怪物数量无变化。
  • 诡异的是，tcmalloc总内存完全没有反映内存的增长。

3. 分析过程

最初始的怀疑对象是新引入的腾讯的behaviac组件，因为刷怪之后内存涨得特别明显。经过简单地查找，发现behaviac组件确实有自己的内存分配器。进一步分析发现，behaviac组件只是有一层内存池的管理，它还是用系统的malloc等接口申请内存。也就是说，我们项目里behaviac组件也是通过tcmalloc分配内存，不是这个组件的问题。

所以，只剩一条路，gdb下函数断点。内存申请的点多，下个函数断点打日志。当时的gdb命令没记下来，信手写一下吧，大概长得这个样子。

1
2
3
4
5
6
7
b malloc
commands
silent
printf "size:%d\n", size
bt
cont
end

断了几个分配的接口，发现打印的分配值和实际增长值都对不上。最后，负责副本的骏图同学(当年招到的一位特别靠谱的同事，服务器出身，新项目负责客户端渲染，水面/人物材质做得很漂亮。低调，不玩朋友圈不发博，所以没链接，面试不招是损失)把这个函数锁定在了mmap。多采样几次，看看共同点，下面是从聊天记录里挖出来的两个堆栈，前一张来自骏图，后一张我的。
mmap stack

mmap stack

堆栈大致分三个部分，由下到上分别是

  • 我们的逻辑，析构内存，上层逻辑各有不同。
  • tcmalloc, tcmalloc的逻辑都是free时调用libunwind记录堆栈。free的堆栈做什么用的呢？如果一个地址被free了，他不会立马回到备用池里，而是放到另外一个暂存的池子。如果地址还继续被引用，tcmalloc可以凭此打印free的堆栈。扯远了，先回来，内存分配器改天开篇聊。不过这种逻辑，debug版本才会有，编译release版本试了一下，果然就不漏了。
  • libuwind, 取堆栈

Debug版本的也得解决啊，节操问题。直觉上怀疑是tcmalloc 64bit下暂存的池子太大了（上图frame 16），调试一看，按字节算的，撑死10MB
free_queue

free_queue_size

在往上看frame 15，源码如下，MallocBlockQueueEntry传了16个指针数组给libunwind填空，和libunwind的交互不需要再分配什么内存，tcmalloc也不需要调libunwind接口释放什么东西， 所以就libunwind自己申请的得自己管理，这样子的话，就是libunwind漏了。
get_caller_stack

仔细看堆栈，libunwind部分也不完全一样，一阵小郁闷，libunwind咱不熟。不过这库挺老了，用的人多，应该会有人报bug，遂Google “libunwind memory leak”。果不其然，真找着了，链接。

我们用的版本是libunwind-0.99-beta，tcmalloc推荐版，老了，和链接里的Patch代码长得不一样，照着描，core了几次之后最终版diff如下，中间过程也不表了。好吧，老实说不记得了，其实我现在看回改过的代码也挺懵B的，算了，不是研究这个的。。。好吧，我还是记得只是一些先后顺序的出了问题，但是读者不会满意的:(。

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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
---
 src/dwarf/Gparser.c | 31 +++++++++++++++++--------------
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/src/dwarf/Gparser.c b/src/dwarf/Gparser.c
index 01a3743..594c26f 100644
--- a/src/dwarf/Gparser.c
+++ b/src/dwarf/Gparser.c
@@ -383,11 +383,11 @@ fetch_proc_info (struct dwarf_cursor *c, unw_word_t ip, int need_unwind_info)
 
   --ip;
 
+  memset (&c->pi, 0, sizeof (c->pi));
+
   if (c->pi_valid && !need_unwind_info)
     return 0;
 
-  memset (&c->pi, 0, sizeof (c->pi));
-
   /* check dynamic info first --- it overrides everything else */
   ret = unwi_find_dynamic_proc_info (c->as, ip, &c->pi, need_unwind_info,
 				     c->as_arg);
@@ -417,9 +417,10 @@ parse_dynamic (struct dwarf_cursor *c, unw_word_t ip, dwarf_state_record_t *sr)
 static inline void
 put_unwind_info (struct dwarf_cursor *c, unw_proc_info_t *pi)
 {
-  if (!c->pi_valid)
-    return;
-
+//https://lists.nongnu.org/archive/html/libunwind-devel/2013-04/msg00000.html
+//  if (!c->pi_valid)
+//    return;
+//
   if (c->pi_is_dynamic)
     unwi_put_dynamic_unwind_info (c->as, pi, c->as_arg);
   else if (pi->unwind_info);
@@ -782,19 +783,20 @@ static int
 uncached_dwarf_find_save_locs (struct dwarf_cursor *c)
 {
   dwarf_state_record_t sr;
-  int ret;
+  int ret = 0;
 
   if ((ret = fetch_proc_info (c, c->ip, 1)) < 0)
-    return ret;
+    goto out;
 
   if ((ret = create_state_record_for (c, &sr, c->ip)) < 0)
-    return ret;
+    goto out;
 
   if ((ret = apply_reg_state (c, &sr.rs_current)) < 0)
-    return ret;
+    goto out;
 
+out:
   put_unwind_info (c, &c->pi);
-  return 0;
+  return ret < 0 ? ret : 0;
 }
 
 /* The function finds the saved locations and applies the register
@@ -845,10 +847,10 @@ dwarf_find_save_locs (struct dwarf_cursor *c)
   c->hint = rs->hint;
   c->prev_rs = rs - cache->buckets;
 
+out:
   put_unwind_info (c, &c->pi);
-  ret = apply_reg_state (c, rs);
+  if(ret >= 0) { ret = apply_reg_state (c, rs); }
 
-out:
   put_rs_cache (c->as, cache, &saved_mask);
   return ret;
 
@@ -876,6 +878,7 @@ dwarf_make_proc_info (struct dwarf_cursor *c)
       || get_cached_proc_info (c) < 0)
 #endif
     /* Lookup it up the slow way... */
-    return fetch_proc_info (c, c->ip, 0);
-  return 0;
+  int ret = fetch_proc_info (c, c->ip, 0);
+  put_unwind_info (c, &c->pi);
+  return ret;
 }
--

4. 后记

总结一下，这问题刚开始认为是刷怪的问题，其实是刷怪了之后，内存分配释放比较频繁，把问题暴露了出来，让副本的同学背了会儿锅。
然后，这个逻辑是debug版才有，怪不得x86和x64做机器人压测比较的时候，也没发现。

展开全文 >>

服务器x64升级之luajit gc64

1. 背景

是的，2018年以前，我们的服务器是32位程序，超过4GB内存会挂。

这其中很大一部分原因是luajit 2.1版本前内存受限（原因见链接），一个vm只支持不超过2GB的内存（看下面的图里的编译选项，MAP_32BIT 只能1G，开了LJ_ALLOC_MMAP_PROBE能到2G, GC64往下看。。。 oh,no,写文档前一直以为MAP_32BIT是2G，没实践过，前面的链接也没仔细看），32位程序反而没这个限制。

另外一个原因是，够用。当然，发生内存泄漏的时候，总会心慌慌。

2018年我们开启了新项目，luajit 2.1分支从提交上看趋于稳定，是时候趁此机会往前走一步了。

2. 编译

直接用git上最新代码，不过得选对分支，默认master是2.0（我就这样掉了一下坑），看来一下今年以来的改动基本都是修修小bug，影响不大，应该是稳定了。

在Makefile里打开GC64选项，为了方便gdb，把调试符号给加上。

1
2
3
4
5
6
7
# Uncomment the next line to generate debug information:
CCDEBUG= -g

...

# Enable GC64 mode for x64.
XCFLAGS+= -DLUAJIT_ENABLE_GC64

编译，测试，不行，调。关键字mmap，找到这段代码。

luajit_call_mmap

宏隔开，三段，用“#error msg”编译，用的是LJ_ALLOC_MMAP_PROBE这段。把下面的宏定义取消，重新编译，就ok了。

lj_alloc_macro

(补充一下，仔细看上图，GC64可用多少内存？128TB，够用了，笔者在电信行业见过最大的core dump是46GB，漏着跑了一夜，太大了，mdb都没法加载，之后再也没用过这么大内存的机器了，哈哈哈)

到这里，就差不多了，我们新项目用着没问题。

3. 其他

3.1. lua文件编译的变化

luajit 2.1中lua和luac两个命令合一，都叫luajit，把之前的lua和luac改成软链。
lua_link.png

Makefile（也是我弄的，设计挺轻巧的，改天开篇讲，7年前初始版）相应修改：

1
2
- $(PROJBASE)/lib/bin/luac -o $(DEST_OUTDIR)/{}.lc {}.lua
+ LUA_PATH=$(PROJBASE)/lib/bin/?.lua $(PROJBASE)/lib/bin/luac -O3 -bg {}.lua $(DEST_OUTDIR)/{}.lc

其他改asset版本号自己find + xargs + sed改一下，debug不用设，opt level默认3，lua内断点依然生效，没特别关注，项目跑了几个月，这块没出什么问题。倒是tcmalloc + libunwind出了些问题，下篇讲。

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

哈哈哈