This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Robustifying pretty-printers
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: gdb at sources dot redhat dot com
- Date: Sat, 13 Jun 2009 14:11:33 +0400
- Subject: Robustifying pretty-printers
While playing with pretty-printers and KDevelop, I've got GDB
to "hang", with the below backtrace:
(gdb) where
#0 0xb7d0ed2a in strcmp () from /lib/tls/i686/cmov/libc.so.6
#1 0x081be1a7 in install_variable (var=0x191b0620) at /home/ghost/Work/CodeSourcery/Projects/egdb/gdb-cvs/gdb/varobj.c:1731
#2 0x081beef7 in create_child_with_value (parent=0x8a6e158, index=514255, name=0xb7bf8e14 "[514255]", value=0x191b03d0)
at /home/ghost/Work/CodeSourcery/Projects/egdb/gdb-cvs/gdb/varobj.c:1859
The '514255' above is sufficient to understand what happened. Our beloved GCC fails to emit
proper debug info, therefore a vector is considered in scope before constructor is executed,
and the vector is full of random bits.
Now, what are the best strategies for fix this (assuming GCC won't be
fixed for 10 years to come)? One approach is to make IDE check at what
line the variable is declared, and don't try to pretty-print it unless
the current line is above that. Alternatively, we might need to revive
the code to limit the number of children to fetch, and use some reasonable
limit, like 10. Comments?
- Volodya