Re: [patch] avoid the crash of gdb+pretty printer on initialized local variables

[asmwarrior <asmwarrior@gmail.com>]

On 2011-12-3 0:50, Tom Tromey wrote:
>>>>>> ">" == ext asmwarrior <asmwarrior@gmail.com> writes:
> 
>>> When debugger with python pretty printer, I sometimes get the gdb crash
>>> when I try to show the value of uninitialized local variables.
> 
> gdb should not crash.
> 
> Is this that mingw-builds-only problem that keeps popping up?

Thanks for the reply and comments.
Yes, I guess it is only the mingw gdb problem, I have no linux at the moment, but in the Codeblocks' forum, I hear no Linux users complained this kind of crash of gdb on linux.


> I forget, something to do with not using the right gcc flag?

My app was build with -O0 and -g, no extra flag is used.

> 
>>> The patch is just a work-around/hack to handle this problem.
>>> I just first check if the symbol is a local variable, and then check the
>>> current line SAL is smaller than the variable's declaration line. If
>>> true, which means this local variable is OK to show, if not, than I just
>>> skip it.
> 
> This is not ok.  First, due to optimization, lines can be smeared
> around, leading to the wrong result here.  Second, a variable can be
> trashed for many reasons, like other bugs in the code.  In this second
> case it is still unacceptable for gdb to crash.
> 
> In theory the existing code will detect memory access errors and cause
> printing to stop early.  If you have a case where this doesn't work
> properly, make a reproducible test case.
Yes, agreed, as I said, it is only a work around. I create this patch to only avoid the crash of gdb under mingw.
The sample code below can easily cause the crash under mingw+gdb+python pretty printer.
> 
>>> void fun()
>>> {
>>>     wxString *psty = (wxString*) NULL;
>>>     wxString wxStr(L"wxString");
>>>     wxStr += L" Value";
>>>     std::string stdStr("std::string");
>>>     stdStr.append(" value");
>>>     std::map<int, std::string> m;
>>>     m[0] = "000";
>>>     m[1] = "111";     //break point here, we stop here
> 

It was not easy to catch such crash problem under windows.
By the way, I found a way to debug gdb under Codeblocks' IDE, see:
http://forums.codeblocks.org/index.php/topic,15618.msg105064.html#msg105064

It has some advantages than just debug gdb under command line. (mentioned in the above link post)

Hopefully it will help some Windows user to easily check the crash problem in the future.

asmwarrior
ollydbg from codeblocks' forum