Webserver解决segmentation fault(core dump)段错问问题

前言

在完成了整个项目后，我用make命令编译了server，当我运行./server文件时，出现了段错误

在大量的代码中找出错因并不是一件容易的事，尤其是对新手程序员来说。而寻找bug的过程就像是侦探调查线索追查凶手一样，我们要通过一点一点的蛛丝马迹来剥离表象，找到真凶。

今天，就由我来扮演一次侦探，调查一番这个段错误到底出自谁手。

段错误：我们面临的是什么敌人

在解决问题之前，让我先来了解一下什么是段错误：

"Segmentation fault (core dumped)" 是一种程序运行时错误，通常表示程序试图访问无效的内存地址。这种错误可能由多种原因引起，包括指针错误、数组越界、使用已释放的内存等。

一般情况下，解决段错误的方法是使用gdb调试段错误生成的core文件。但是许多人会发现系统不会生成core dump文件，这是因为 core dump文件是由linux系统进行生成，而且其往往较大，默认情况下，Linux是不允许生成core dump文件的。

我们可以使用

ulimit -c

命令来查看，如果是 0，说明Linux允许的core文件最大大小为0，即不允许生成core文件

这时，我们要使用

ulimit -c unlimited

来将core文件最大大小改为无限。

我们再编译运行程序就会产生core文件，但是默认的core文件生成目录不在本目录，因此需要把默认core文件生成目录改成运行目录，再然后.....

......

这也太麻烦了，有没有更简单的方法。哎，你别说，还真有，接下来我们不借助core文件来"查案"

GDB调试探方向，段错误真相初现端倪

首先，我们在makefile文件里的编译代码加上-g的可选项，这样生成的server就是一个可以用gdb调试的可执行文件。

随后，我们使用gdb命令进入server可执行文件

gdb server

进入gdb调试器以后，我们使用run运行

gdb给出已下报错：

注意看这里的MYSQL Error: mysql_real_connect，虽然gdb告诉我们是在 iofputs.c 的__GI__IO_fputs函数出现的段错误，但是这是系统调用，无数人用了那么多年，不太可能出现错误，所有应该还是我们自己的代码有问题。那我们该从何找起呢？

哎，我们发现这里有一条日志：

MySQL Error : mysql_real_connect\n

这不是我们写的日志吗，太好了，我们终于发现了错误的蛛丝马迹。

深入代码危险区，巧设监控锁暗敌

经过我们的重重调查，我们终于定位到了错误代码函数所在地，即sql_connection_pool.cpp的init函数

void connection_pool::init(string url, string User, string PassWord, string DBName, int MaxConn, int Port, int close_log) {m_url = url;m_Port = Port;m_User = User;m_PassWord = PassWord;m_DatabaseName = DBName;m_close_log = close_log;for (int i = 0; i < MaxConn; ++i) {MYSQL *con = NULL;con = mysql_init(con);if (con == nullptr) {LOG_ERROR("MySQL Error : mysql_init");exit(1);}/*真正的连接函数*/con = mysql_real_connect(con, url.c_str(), User.c_str(), PassWord.c_str(), DBName.c_str(), Port, NULL, 0);if (con == nullptr) {LOG_ERROR("MySQL Error : mysql_real_connect");exit(1);}connList.push_back(con);m_FreeConn++;}reserve = sem(m_FreeConn);//信号量记录共享资源总量m_MaxConn = m_FreeConn;
}

其中，GDB告诉我们的线索即是这里的”人证“给出的 , 即第22行的

LOG_ERROR("MySQL Error : mysql_real_connect");

让我们看看这个函数里的关键API：mysql_init和mysql_real_connect

mysql_init 是 MySQL C API 中的一个函数，用于初始化和分配一个 MYSQL 结构，这个结构是用于表示 MySQL 连接的句柄。这个函数通常是在开始使用 MySQL C API 之前调用的，以确保连接句柄是有效的。

mysql_real_connect 函数是 MySQL C API 中的一个关键函数，用于建立与 MySQL 服务器的连接

可见，这个函数是通过mysql_init创建句柄，再用该句柄创建mysql连接

咋一看好像这一块的代码都没有问题，那是怎么回事了？

为了深一步调查，我们使用时空回溯大法，我们在这里设下”监控“，重现当时的”犯罪场景“，那么我们该如何设下监控呢？其实很简答，就是我们在c++中常用debug方法，在程序中打印出调试信息，这里我们就在第19行代码

con = mysql_real_connect(con, url.c_str(), User.c_str(), PassWord.c_str(), DBName.c_str(), Port, NULL, 0);

的前后，分别写上

cout<<"before mysql_real_connect"<<endl;
con = mysql_real_connect(con, url.c_str(), User.c_str(), PassWord.c_str(), DBName.c_str(), Port, NULL, 0);
cout<<"after mysql_real_connect"<<endl;

然后我们再编译运行，出现以下结果：

可以看到，程序并非是没进入mysql_real_connect就报错，而是循环了无数遍后才出现的报错；这是怎么回事了，为了清晰地看到循环次数，我们为“监控”加上计数器

cout<<"第"<<i<<"次 before mysql_real_connect"<<endl;
con = mysql_real_connect(con, url.c_str(), User.c_str(), PassWord.c_str(), DBName.c_str(), Port, NULL, 0);
cout<<"第"<<i<<"次 after mysql_real_connect"<<endl;

可以看到，程序循环了151次后就结束了，随后发生了段错误。这是什么原因？让我们接着“调查”。

日夜辗转寻真相，辛勤探寻不负望

经过前面的“调查”，我们得到了线索，再init循环中，当程序循环151次，第152次就发生了段错误。没办法，我们先去调查一下是谁调用了init

我们发现，调用该函数的是WebServer.cpp的void sql_pool()函数，而且该函数给init的循环上限MaxConn设置的是3306

void WebServer::sql_pool() {/*初始化数据库连接池*/m_connPool = connection_pool::Getinstance();m_connPool->init("localhost", m_user, m_passWord, m_databaseName, 3306, m_sql_num, m_close_log);/*初始化数据库读取表*/users->initmysql_result(m_connPool);
}

我们对比一下m_connPool的定义，发现了问题所在

void connection_pool::init(string url, string User, string PassWord, string DBName,  int MaxConn, int Port,int close_log)

原来是因为Port和MaxConn在定义在前的为端口，定义在后的为循环上限了，导致了端口号被用来当循环的上限；而数据库最大能创建的连接数是152，超出了152自然就触发了段错误；那么，我们将调用init的地方改过来即可。

后记

经过不懈的努力，我终于是解决了这个BUG。但其实在解决bug的过程中我并不像文章中说的那么容易，包括最开始我为了去得到 core文件，找了许多方法，也花了很多时间，但是一直没有什么显著效果。中间我一度沮丧到想哭。最后也是不管三七二十一用GDB运行了一次server文件才找到了一点点蛛丝马迹。而后面在发现循环151次后就会段错误的时候，我也一度找错了方向，找了许多方法，把数据库的连接上限改成3500，系统能容纳的最大文件描述符也被我改成了3500，如下图