Re: About the "info locals" command of gdb and python pretty printer

Re: About the "info locals" command of gdb and python pretty printer

[asmwarrior]

Hi, all. About the "info locals" and python pretty printer problem I 
post here:
http://sourceware.org/ml/gdb/2010-06/msg00080.html

see the result here:
http://forums.codeblocks.org/index.php/topic,12747.msg86443.html#msg86443

I have solved this problem by hacking the GDB source code. You can see 
the changed code here:

http://sourceware.org/bugzilla/show_bug.cgi?id=11407#c33


Asmwarrior (ollydbg from codeblocks' forum)

About the "info locals" command of gdb and python pretty printer

[asmwarrior]

Hi, I have some problems to show some uninitialized local variables.

For example, here is the test code:

void test()
{
     int aaaa = 1;
     int bbbb = 2;
     int cccc = 3;
}

int main()
{
     test();
     return 0;
}

Here, if I set a breakpoint at the first statement of the "test()", then 
run "info locals" command. gdb will plot all the information about both 
"aaaa, bbbb and cccc".

Things becomes more complex when bbbb and cccc are not simple type, but 
instead, they are stl containers like vector<int> or maps.
like:

void test()
{
     int aaaa = 1;
     vector <int> bbbb;
     map<int,string>cccc;
}

At this time, if we run the "info locals" with python stl pretty printer 
enabled, as you see, if you breakpoint is still at the first line "int 
aaa = 1;", then bbbb and cccc are not initialized, this may cause the 
python script to plot random values, some times, gdb or python will get 
crashed.
A more detailed discussion can be found :
http://sourceware.org/bugzilla/show_bug.cgi?id=11407

Also, this kind of problem is exist some other situations, In the 
QTCreator's manual:
http://doc.qt.nokia.com/qtcreator-1.2/creator-debugging.html
> The debug information provided by gcc does not include enough 
> information about the time when a variable is initialized. Therefore, 
> Qt Creator can not tell whether the contents of a local variable 
> contains "real data", or "initial noise". If a QObject appears 
> uninitialized, its value will be reported as "out of scope". However, 
> not all uninitialized objects can be recognized as such.

I asked this kind of question on the GCC maillist, some one replies in 
this post:
http://gcc.gnu.org/ml/gcc/2010-06/msg00633.html
He suggest that we can use the GCC option: -fvar-tracking

With this option, the variable location was recorded in the output file. 
I have just do a test on my first example code. (I tested under MinGW 
GCC 4.4.4)

objdump -W MyTarget.exe >> log.txt
will give all the debug information, like below:

-----------------------------------
...
<1><5f>: Abbrev Number: 2 (DW_TAG_subprogram)
<60>   DW_AT_external    : 1
<61>   DW_AT_name        : test
<66>   DW_AT_decl_file   : 1
<67>   DW_AT_decl_line   : 1
<68>   DW_AT_MIPS_linkage_name: _Z4testv
<71>   DW_AT_low_pc      : 0x4013d0
<75>   DW_AT_high_pc     : 0x4013ed
<79>   DW_AT_frame_base  : 0x0    (location list)
<7d>   DW_AT_sibling     : <0xb9>
<2><81>: Abbrev Number: 3 (DW_TAG_lexical_block)
<82>   DW_AT_low_pc      : 0x4013d6
<86>   DW_AT_high_pc     : 0x4013eb
<3><8a>: Abbrev Number: 4 (DW_TAG_variable)
<8b>   DW_AT_name        : aaaa
<90>   DW_AT_decl_file   : 1
<91>   DW_AT_decl_line   : 3
<92>   DW_AT_type        : <0xb9>
<96>   DW_AT_location    : 2 byte block: 75 74     (DW_OP_breg5: -12)
<3><99>: Abbrev Number: 4 (DW_TAG_variable)
<9a>   DW_AT_name        : bbbb
<9f>   DW_AT_decl_file   : 1
<a0>   DW_AT_decl_line   : 4
<a1>   DW_AT_type        : <0xb9>
<a5>   DW_AT_location    : 2 byte block: 75 78     (DW_OP_breg5: -8)
<3><a8>: Abbrev Number: 4 (DW_TAG_variable)
<a9>   DW_AT_name        : cccc
<ae>   DW_AT_decl_file   : 1
<af>   DW_AT_decl_line   : 5
<b0>   DW_AT_type        : <0xb9>
<b4>   DW_AT_location    : 2 byte block: 75 7c     (DW_OP_breg5: -4)
<1><b9>: Abbrev Number: 5 (DW_TAG_base_type)
<ba>   DW_AT_byte_size   : 4
<bb>   DW_AT_encoding    : 5    (signed)
<bc>   DW_AT_name        : int
...
----------------------------------------
So, you can see, there are some information about "DW_AT_decl_line", 
this information tells us that this variable is initialized after this 
line.

So, I think if GCC can use this information, then we can nicely solved 
the "info locals" command problem.

Any ideas?

By the way, there are other ways to give the "DW_AT_start_scope" 
information about a variable, but Currently, GCC don't have this kind of 
debug information generated. See here: 
http://gcc.gnu.org/ml/gcc/2007-04/msg00138.html


Thanks for reading my post.

asmwarrior ollydbg from codeblocks' forum

Re: About the "info locals" command of gdb and python pretty printer

[André Pönitz]

On Sunday 20 June 2010 11:13:20 asmwarrior wrote:
> Hi, I have some problems to show some uninitialized local variables.
> 
> For example, here is the test code:
> 
> void test()
> {
>      int aaaa = 1;
>      int bbbb = 2;
>      int cccc = 3;
> }
> 
> int main()
> {
>      test();
>      return 0;
> }
> 
> Here, if I set a breakpoint at the first statement of the "test()", then 
> run "info locals" command. gdb will plot all the information about both 
> "aaaa, bbbb and cccc".
> 
> Things becomes more complex when bbbb and cccc are not simple type, but 
> instead, they are stl containers like vector<int> or maps.
> like:
> 
> void test()
> {
>      int aaaa = 1;
>      vector <int> bbbb;
>      map<int,string>cccc;
> }
> 
> At this time, if we run the "info locals" with python stl pretty printer 
> enabled, as you see, if you breakpoint is still at the first line "int 
> aaa = 1;", then bbbb and cccc are not initialized, this may cause the 
> python script to plot random values, some times, gdb or python will get 
> crashed.

As data "damaged" after the initialization can look pretty much like
uninitialized data, taking the scope information into account would
not solve the problem, only reduce the likelihood of running into it.

Andre'

Re: About the "info locals" command of gdb and python pretty printer

[Tom Tromey]

>>>>> ">" == Asm gmail <asmwarrior@gmail.com> writes:

>> At this time, if we run the "info locals" with python stl pretty
>> printer enabled, as you see, if you breakpoint is still at the first
>> line "int aaa = 1;", then bbbb and cccc are not initialized, this may
>> cause the python script to plot random values, some times, gdb or
>> python will get crashed.

I think the real problem here is that gdb crashed.  That should not
happen.  Can you find out what went wrong?

Python exceptions are "normal" in the sense that they should not cause
gdb any problems.

We should fix the problem that exceptions during pretty-printing can
cause problems.  I think there are a few parts to this.  We
should differentiate the different types of gdb exception in Python, so
that things like memory errors can cause nicer behavior.  We should also
make lazy strings truly lazy during printing.  This will eliminate some
problems when trying to print a lazy string with length==-1.

Tom

Re: About the "info locals" command of gdb and python pretty printer

[asmwarrior]

On 2010-6-22 4:08, Tom Tromey wrote:
>
>>> At this time, if we run the "info locals" with python stl pretty
>>> printer enabled, as you see, if you breakpoint is still at the first
>>> line "int aaa = 1;", then bbbb and cccc are not initialized, this may
>>> cause the python script to plot random values, some times, gdb or
>>> python will get crashed.
>>>        
> I think the real problem here is that gdb crashed.  That should not
> happen.  Can you find out what went wrong?
>
> Python exceptions are "normal" in the sense that they should not cause
> gdb any problems.
>
> We should fix the problem that exceptions during pretty-printing can
> cause problems.  I think there are a few parts to this.  We
> should differentiate the different types of gdb exception in Python, so
> that things like memory errors can cause nicer behavior.  We should also
> make lazy strings truly lazy during printing.  This will eliminate some
> problems when trying to print a lazy string with length==-1.
>
> Tom
>    
Hi, Tom, thanks for your reply. I also noticed your reply in
http://sourceware.org/bugzilla/show_bug.cgi?id=11407#c34
As you said, GDB should be robust, so that even it has some exceptions 
from python. (Or python script will call internally some gdb command, at 
that time, gdb has some exception too).

I'm not sure how to get a "stack track" when gdb crashed. Do I need to 
run GDB under GDB. So, the debuggee GDB get crashed, the debugger GDB 
can generate some stack trace inforamtion?

Thanks

Asmwarrior

Re: About the "info locals" command of gdb and python pretty printer

[Tom Tromey]

>>>>> ">" == Asm gmail <asmwarrior@gmail.com> writes:

>> I'm not sure how to get a "stack track" when gdb crashed. Do I need to
>> run GDB under GDB. So, the debuggee GDB get crashed, the debugger GDB
>> can generate some stack trace inforamtion?

Yes.  Or at least, try that, and if it does not work we may need to look
into alternatives.

Tom

Re: About the "info locals" command of gdb and python pretty printer

[Tom Tromey]

>>>>> ">" == Asm gmail <asmwarrior@gmail.com> writes:

>> 1, It seems the current SVN std python script didn't works any
>> more.
[...]
>> All the response from gdb just gives the same as print /r XXXX.

I think this is pretty unlikely to have been caused by the recent patch.
Instead it sounds like the printers aren't being read in.

What version of Python are you using?

>> Today, I have build  gdb-cvs-20100623 , and try to make gdb crash on
>> printing some uninitialized stl containers by pretty printers. But it
>> stands through all the cases, so, it seems the gdb-cvs-20100623 is
>> quite stable than the gdb-cvs-20100619. I'm not sure what has
>> changed. It seems it more stable now.

As far as I know, nothing in this area has changed.

Tom

Re: About the "info locals" command of gdb and python pretty printer

[asmwarrior]

On 2010-6-24 4:28, Tom Tromey wrote:
> I think this is pretty unlikely to have been caused by the recent patch.
> Instead it sounds like the printers aren't being read in.
>
> What version of Python are you using?
>
>    
Thanks for the reply
I use python stable 2.6.5 version on Windows.
http://www.python.org/ftp/python/2.6.5/python-2.6.5.msi

asm

Re: About the "info locals" command of gdb and python pretty printer

[Matthias Klose]

On 23.06.2010 22:28, Tom Tromey wrote:
>>>>>> ">" == Asm gmail<asmwarrior@gmail.com>  writes:
>
>>> 1, It seems the current SVN std python script didn't works any
>>> more.
> [...]
>>> All the response from gdb just gives the same as print /r XXXX.
>
> I think this is pretty unlikely to have been caused by the recent patch.
> Instead it sounds like the printers aren't being read in.
>
> What version of Python are you using?
>
>>> Today, I have build  gdb-cvs-20100623 , and try to make gdb crash on
>>> printing some uninitialized stl containers by pretty printers. But it
>>> stands through all the cases, so, it seems the gdb-cvs-20100623 is
>>> quite stable than the gdb-cvs-20100619. I'm not sure what has
>>> changed. It seems it more stable now.
>
> As far as I know, nothing in this area has changed.

my mistake. I did check in two chunks left over from testing. Reverted these on 
the trunk. The 4.5 branch was not affected. Sorry.

   Matthias