关于 MySQL-Proxy 子进程异常退出的问题，我已经在之前的博文中提到过：

相关的错误信息如下图所示：

经查阅11号信号为SIGSEGV，表示进程执行了一个无效的内存引用或发生段错误，从而导致子进程异常退出。

我们知道 MySQL-Proxy 采用的是父子进程的模式，处理请求都是由子进程来完成的，而父进程只起到监控子进程的作用， 我们一般会在 MySQL-Proxy 的配置文件中添加“keepalive=true”参数，以确保在子进程异常退出时，由父进程自动将其拉起。

刚开始定位到以下两个源码文件：

src/chassis-unix-daemon.c

src/chassis-mainloop.c

在其中看到了对 SIGTERM/SIGINT/SIGHUP 三个信号的处理，于是也按照类似的方法添加了对 SIGSEGV 信号的处理(将其信号忽略掉)，修改大致如下：

src/chassis-unix-daemon.c:

signal(SIGSEGV, chassis_unix_signal_forward);

......

signal(SIGSEGV, SIG_DFL);

src/chassis-mainloop.c:

struct event ev_sigterm, ev_sigint, ev_sigsegv;

......

signal_set(&ev_sigsegv, SIGSEGV, sigsegv_handler, NULL);

event_base_set(chas->event_base, &ev_sigsegv);

signal_add(&ev_sigsegv, NULL);

......

signal_del(&ev_sigsegv);

虽然不再报错，也能正常工作，但好景不长，5分钟左右就挂掉了。因为我们将 SIGSEGV 信号忽略掉了，子进程异常退出时，父进程收不到导致子进程异常退出的 SIGSEGV 信号，当然也就无法正常将其子进程拉起，所以此方法不能解决我们的问题。

既然以上方法不能解决我们的问题，于是就想到了通过开启 coredump 的方式来进行调试追踪，设置如下：

# ulimit -c unlimited

# echo "1" > /proc/sys/kernel/core_uses_pid

# mkdir -p /root/corefile

# echo "/root/corefile/core-%e-%p-%t" > /proc/sys/kernel/core_pattern

重新编译 MySQL-Proxy(注意要加上“-g”参数)：

# ./configure --prefix=/usr/local/mysql-proxy \

--with-lua=/usr/local/lua \

--with-mysql=/usr/local/mysql \

GLIB_CFLAGS="-I/usr/local/glib-2.32.4/include/glib-2.0" \

GLIB_LIBS="-L/usr/local/glib-2.32.4/lib/glib-2.0 -lglib-2.0" \

GMODULE_CFLAGS="-I/usr/local/glib-2.32.4/include" \

GMODULE_LIBS="-L/usr/local/glib-2.32.4/lib -lgmodule-2.0" \

GTHREAD_CFLAGS="-I/usr/local/glib-2.32.4/include" \

GTHREAD_LIBS="-L/usr/local/glib-2.32.4/lib -lgthread-2.0" \

LDFLAGS="-L/usr/local/lib -lm -L/usr/local/lib64 -lcrypto" \

LUA_CFLAGS="-I/usr/local/lua/include" \

LUA_LIBS="-L/usr/local/lua/lib -llua-5.1 -ldl" \

CFLAGS="-DHAVE_LUA_H-g"

# make && make install

再次启动编译后的 MySQL-Proxy 程序，几分钟后会生成如下core文件：

采用 GDB 进行追踪调试：

# cd /usr/local/mysql-proxy/bin

# gdb ./mysql-proxy /root/corefile/core-mysql-proxy-32354-1400039241

得到如下信息：

通过参考360的Atlas源码，我们最终定位到network-conn-pool-lua.c中的network_connection_pool_lua_add_connection函数，修改如下：

修改前：

修改后：

我们可以在 360 Atlas 的对应修改位置，看到如下信息，我想大家应该明白是什么原因引起了吧！！！

经测试，一切 OK ！！！