* About the "info locals" command of gdb and python pretty printer
@ 2010-06-20 9:13 asmwarrior
2010-06-21 7:48 ` André Pönitz
2010-06-21 20:08 ` Tom Tromey
0 siblings, 2 replies; 10+ messages in thread
From: asmwarrior @ 2010-06-20 9:13 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About the "info locals" command of gdb and python pretty printer
2010-06-20 9:13 About the "info locals" command of gdb and python pretty printer asmwarrior
@ 2010-06-21 7:48 ` André Pönitz
2010-06-21 20:08 ` Tom Tromey
1 sibling, 0 replies; 10+ messages in thread
From: André Pönitz @ 2010-06-21 7:48 UTC (permalink / raw)
To: gdb
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'
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About the "info locals" command of gdb and python pretty printer
2010-06-20 9:13 About the "info locals" command of gdb and python pretty printer asmwarrior
2010-06-21 7:48 ` André Pönitz
@ 2010-06-21 20:08 ` Tom Tromey
2010-06-22 0:29 ` asmwarrior
` (2 more replies)
1 sibling, 3 replies; 10+ messages in thread
From: Tom Tromey @ 2010-06-21 20:08 UTC (permalink / raw)
To: asmwarrior; +Cc: gdb
>>>>> ">" == 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About the "info locals" command of gdb and python pretty printer
2010-06-21 20:08 ` Tom Tromey
@ 2010-06-22 0:29 ` asmwarrior
2010-06-22 2:18 ` Tom Tromey
2010-06-23 12:30 ` asmwarrior
[not found] ` <4C21FCDC.5050503__12891.7291098789$1277296251$gmane$org@gmail.com>
2 siblings, 1 reply; 10+ messages in thread
From: asmwarrior @ 2010-06-22 0:29 UTC (permalink / raw)
To: tromey; +Cc: gdb
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About the "info locals" command of gdb and python pretty printer
2010-06-22 0:29 ` asmwarrior
@ 2010-06-22 2:18 ` Tom Tromey
0 siblings, 0 replies; 10+ messages in thread
From: Tom Tromey @ 2010-06-22 2:18 UTC (permalink / raw)
To: asmwarrior; +Cc: gdb
>>>>> ">" == 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Re: About the "info locals" command of gdb and python pretty printer
2010-06-21 20:08 ` Tom Tromey
2010-06-22 0:29 ` asmwarrior
@ 2010-06-23 12:30 ` asmwarrior
[not found] ` <4C21FCDC.5050503__12891.7291098789$1277296251$gmane$org@gmail.com>
2 siblings, 0 replies; 10+ messages in thread
From: asmwarrior @ 2010-06-23 12:30 UTC (permalink / raw)
To: tromey; +Cc: gdb, libstdc++, Matthias Klose
Hi, I have two things to say: (it is both related to python pretty
printer and the gdb, so I send it to both mail lists, sorry for the
incovience)
------------------------------------------------------------------------------
1, It seems the current SVN std python script didn't works any more. So,
this my be a regression.
svn://gcc.gnu.org/svn/gcc/trunk/libstdc++-v3/python
It seems there is a commit in
Revision: 161233
Author: doko
Message:
2010-06-22 Matthias Klose <doko@ubuntu.com>
* python/libstdcxx/v6/printers.py: Don't use string exceptions.
----
Modified : /trunk/libstdc++-v3/ChangeLog
Modified : /trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
But I found that this revision didn't work any more, I try to print out
some vector, list. (I have tested under Windows XP, MinGW 4.5 and MinGW
4.4.4, GDB cvs 20100623)
All the response from gdb just gives the same as print /r XXXX.
------------------------------------------------------------------------------
2, @tom
On 3:59, Tom Tromey wrote:
>>>>>> ">" == 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
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.
By the way, I will report if it crashed again.
Thanks
Asmwarrior ollydbg from codeblocks' forum.
^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <4C21FCDC.5050503__12891.7291098789$1277296251$gmane$org@gmail.com>]
* Re: About the "info locals" command of gdb and python pretty printer
[not found] ` <4C21FCDC.5050503__12891.7291098789$1277296251$gmane$org@gmail.com>
@ 2010-06-23 20:28 ` Tom Tromey
2010-06-24 1:16 ` asmwarrior
2010-07-02 10:57 ` Matthias Klose
0 siblings, 2 replies; 10+ messages in thread
From: Tom Tromey @ 2010-06-23 20:28 UTC (permalink / raw)
To: asmwarrior; +Cc: gdb, libstdc++, Matthias Klose
>>>>> ">" == 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About the "info locals" command of gdb and python pretty printer
2010-06-23 20:28 ` Tom Tromey
@ 2010-06-24 1:16 ` asmwarrior
2010-07-02 10:57 ` Matthias Klose
1 sibling, 0 replies; 10+ messages in thread
From: asmwarrior @ 2010-06-24 1:16 UTC (permalink / raw)
To: tromey; +Cc: gdb, libstdc++, Matthias Klose
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About the "info locals" command of gdb and python pretty printer
2010-06-23 20:28 ` Tom Tromey
2010-06-24 1:16 ` asmwarrior
@ 2010-07-02 10:57 ` Matthias Klose
1 sibling, 0 replies; 10+ messages in thread
From: Matthias Klose @ 2010-07-02 10:57 UTC (permalink / raw)
To: tromey; +Cc: asmwarrior, gdb, libstdc++
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: About the "info locals" command of gdb and python pretty printer
@ 2010-06-21 3:02 asmwarrior
0 siblings, 0 replies; 10+ messages in thread
From: asmwarrior @ 2010-06-21 3:02 UTC (permalink / raw)
To: gdb; +Cc: gcc
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)
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-07-02 10:57 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-20 9:13 About the "info locals" command of gdb and python pretty printer asmwarrior
2010-06-21 7:48 ` André Pönitz
2010-06-21 20:08 ` Tom Tromey
2010-06-22 0:29 ` asmwarrior
2010-06-22 2:18 ` Tom Tromey
2010-06-23 12:30 ` asmwarrior
[not found] ` <4C21FCDC.5050503__12891.7291098789$1277296251$gmane$org@gmail.com>
2010-06-23 20:28 ` Tom Tromey
2010-06-24 1:16 ` asmwarrior
2010-07-02 10:57 ` Matthias Klose
2010-06-21 3:02 asmwarrior
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).