dbtool一bug跟踪记

Posted 皇家救星

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了dbtool一bug跟踪记相关的知识,希望对你有一定的参考价值。

  注:这篇日志是好多年前,我还在从兴公司时写的。现在都从从兴公司离职很久了,从兴也没落了,可惜。看了一下,虽然出现了部分代码,但不至于泄漏什么机密,查bug过程的原理也有可以让新手借鉴的地方,就原文照搬上来了。

  dbtool是营帐研发部常用的一个类sqlplus数据库查询工具,它提供了较sqlplus更友好的输出界面,十分适合在命令行下操作,故在部门内部使用相当广泛。

       不过它一直有一个bug,使用过程中偶尔会出现执行某条sql后core down的情况。但是由于这种情况较少见,而且bug出现随机性太大,所以一直也没人去管它。

       今天早上加班过程中,居然又让我碰上这个bug了。不过这次bug很有规律,每次连接上数据库后立即执行“select userenv(‘language‘) from dual;”程序立即core down。

       由于是周日,比较有空,而且天赐良机,居然能重现bug,于是决定花点时间解决这个bug。

       首先使用dbx看一下程序在哪core

Segmentation fault(coredump)
bbkf:/home/report/c++/report/dbtool$dbx dbtool
Type help for help.
[using memory image in core]
reading symbolic information ...

Segmentation fault in malloc_y at 0x90000000005bb10 ($t1)
0x90000000005bb10 (malloc_y+0x5a4) 90050000         stw   r0,0x0(r5)
(dbx) where
malloc_y(0xa1, 0x0, 0x0, 0x7f7f7f7f, 0x2, 0x2d2d0049, 0x2d, 0x100233704) at 0x90000000005bb10
malloc_common_79_63(??) at 0x900000000058948
_Fancy_malloc__FUl(??) at 0x900000000451ae4
__nw__FUl(??) at 0x9000000004517c0
_Allocate__3stdHc_UlPc_Pc(??, ??) at 0x9000000004c5834
allocate__Q2_3std9allocatorXTc_FUlPCv(??, ??, ??) at 0x9000000004c57c4
_Copy__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FUl(??, ??) at 0x9000000004c564c
_Grow__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FUlb(??, ??, ??) at 0x9000000004c4ec8
assign__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FPCcUl(??, ??, ??) at 0x9000000004c4bac
assign__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FPCc(??, ??) at 0x9000000004c4974
__ct__Q2_3std12basic_stringXTcTQ2_3std11char_traitsXTc_TQ2_3std9allocatorXTc__FPCc(??, ??) at 0x9000000004c4880
GetColNameDisplay(std::basic_string<char,std::char_traits<char>,std::allocator<char> >&,std::basic_string<char,std::char_traits<char>,std::allocator<char> >&)(this = 0x0fffffffffffaba8, colsName = &(...), prompt = &(...)), line 884 in "cmdDeal.cpp"
GetDBData(int)(this = 0x0fffffffffffaba8, bAutoContinue = 0), line 580 in "cmdDeal.cpp"
CCmdDeal::Run()(this = 0x0fffffffffffaba8), line 273 in "cmdDeal.cpp"
main(argc = 2, argv = 0x0ffffffffffff338), line 249 in "dbtool.cpp"
(dbx)

 

 

  从上面可以看到,出错位置在string里面,根据经验,这种bug好解决,一般是string操作错误,例如将一个没有结尾的字符数组赋值给string

       用vi打开cmdDeal.cpp,定位到884行,发现如下代码

 

  +875  int CCmdDeal::GetColNameDisplay(string &colsName, string &prompt)
  +876  {
  +877          char chSplit = ‘ ‘;
  +878          int i, len = 0;
  +879          int rows = 0;
  +880          int maxNameLen = 0;
  +881          int lineSize = 0;
  +882          int displayMode = 0;
  +883          string s;
  +884          string str45 = "-------------------------------------------------------------------"
  +885                                     "-------------------------------------------------------------------";

       居然是正常的字符串初始化出错! 这就郁闷了,这行代码怎么看都是正常的,根据经验,这种正常的代码出错,一般是由于前面某个位置出现了越界操作导致的。这种错误相对难查很多。

       浏览了一下附近的代码,都没发现什么异常的代码,于是只能加上一些调试代码看能不能找出问题。经过一番尝试后发现,在GetColNameDisplay里面初始化长度较大的字符串就会导致程序core down。并且这个规律在GetDBData(调用GetColNameDisplay的函数)里面也有效。

       这就好办了,只要找出在哪段代码执行后会出现这种奇怪的现象,问题代码应该就在那。

  于是在程序里面加了N多个下面的代码片段

1 {
2     string str45 = "-------------------------------------------------------------------"
3                                        "-------------------------------------------------------------------";
4 string str451 = "-------------------------------------------------------------------"
5                                        "-------------------------------------------------------------------";
6     printf("[%s:%d]
", __FILE__, __LINE__);
7 }

 

       上面的调试代码特意括在大括号里面的,目的有两个,

  1 括号使得str45变成局部变量,这样不会出现变量冲突

  2 保证str45尽快析构,以免影响错误定位

  加上代码后编译运行,看程序在哪两行代码之间挂掉,接着在那两行代码中间增加更多调试代码,反复运行,很快就定位到了出错函数GetColumnInf。程序在调用这个函数之前调试代码执行不会有问题,在之后就挂了。GetColumnInf这个函数比较短,仔细看了一下,发现下面这段代码可能有问题。

      

         

 1 vector<ColInf>::iterator it = m_vecColInf.begin();
 2     int Index = 1;
 3     COciCursor        cur( *m_pOracle );
 4     COciColumnDesc    coldesc;
 5     
 6     cur.Parse(strSql.c_str());
 7     
 8     do
 9     {
10         cur.DescribeColumn( Index, coldesc );
11         if (it->type != 12 && it->type != 1)
12         {
13             it->prec = it->type==12 ? it->prec : coldesc.m_Prec;
14         }
15         it++;
16         Index++;
17     } while ( !cur.EndOfDesc() );
18     cur.Close();

  代码里面对it操作时,没有判断it是否越界,整个函数看起来就这个最可能出现问题了。试着给while循环加了一个判断条件变成“while ( !cur.EndOfDesc() && it != m_vecColInf.end() );”

重新编译运行。

1 [email protected] >select userenv(language) from dual; 
2 
3 USERENV(LANGUA      
4 -------------------------
5 AMERICAN_AMERICA.ZHS16GBK
6 
7 1 rows selected.

 

  猜对了,程序能正确输出,不会再core掉! 接下只需要分析这段代码为何会越界,修复即可。不过一看时间已经十一点多,不知不觉浪费了近半个上午,而且这段代码看起来作用只是获取数据库字段精度,不是很重要,所以此次根跟踪到此为止吧。

 

  此次收获经验:写代码还是谨慎点,加多一些边界判断比较好,不然贪图一时方便可能导致花大把时间在定位bug

以上是关于dbtool一bug跟踪记的主要内容,如果未能解决你的问题,请参考以下文章

python基于SQLAchemy的DBtools

vscode代码片段建议bug

bug诞生记——信号(signal)处理导致死锁

bug诞生记——信号(signal)处理导致死锁

bug诞生记——不定长参数隐藏的类型问题

bug诞生记——不定长参数隐藏的类型问题