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

[Tom Tromey <tromey at redhat dot com>]

>>>>> ">" == 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?
I forget, something to do with not using the right gcc flag?

>> 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.

>> 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

This kind of thing is generally not very reproducible.  It relies on
compiler differences, libraries, runtime differences.  Something that is
plain C and just writes bad values directly would be better.

>> If you try to run "print v", or "info locals", then gdb will crash (I'm
>> using gdb cvs build under WindowsXP, mingw, python 2.7)

>> I believe that this patch will not be applied, because it is just a
>> hack, right?

I think it is actively wrong in some cases.

>> Basically, gdb should alive with out any crash in any condition, but
>> sometimes, I think a workaround is also necessary. I have see that in
>> QTcreator, when they want to show the contents of a stl container, it do
>> many sanity check. like:

>> The length of the std::vector should be positive, and it's size should
>> be limited.
>> Also many other sanity checks

Adding a sanity check to the vector printer would probably be ok.
That is maintained in libstdc++.

Checking the size is probably not ok.  gdb lazily fetch sub-objects; and
respects length limits like "set print elements" or the MI equivalent
for dynamic varobjs.  Having the printer check that the length is "short
enough" is generally wrong for this reason.

Tom