This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

innermost_block-related crash


GDB is crashing on me in the new gdb.cp/ref-params.exp test:

(gdb) bt
#0  contained_in (a=0x86d44b38, b=0x84d43b38)
    at ../../../src/gdb/gdb/block.c:51
#1  0x1c0e763f in c_parse () at c-exp.y:690
#2  0x1c0bcda1 in c_preprocess_and_parse ()
    at ../../../src/gdb/gdb/c-lang.c:472
...
#5  0x1c08d7ab in parse_expression (string=0x88e66086 "f1(QR)")
    at ../../../src/gdb/gdb/parse.c:1159
#6  0x1c05a809 in print_command_1 (exp=0x88e66086 "f1(QR)", inspect=0, 
    voidprint=1) at ../../../src/gdb/gdb/printcmd.c:857
#7  0x1c05a886 in print_command (exp=0x88e66086 "f1(QR)", from_tty=1)
    at ../../../src/gdb/gdb/printcmd.c:904
...
(gdb) p *innermost_block
Cannot access memory at address 0x84d43b38

The backtrace is a bit confusing since frame #1 is in a yacc source
file, but what it boils down to is that innermost_block is a dangling
pointer.  This seems to be related to the fact that the test rereads
the symbols.  Since blocks are generally allocated using the objfile
obstack, this could indeed explain the dangling pointer; the old
objfile was freed, so the obstack isn't there anymore.  And if you're
on a system with a randomizing memory allocator, the obstack for the
new objfile is likely to be in a totally different region of memory.

I'm not sure how to solve this.  Should we simply always set
innermost_block to NULL when we start evaluating a new expression?  Or
should we do that as part of freeing an objfile.  The root of the
problem of course is the abuse of a global variable, but passing down
state through the entire expression evaluation chain imples some major
surgery :(.

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]