Re: [RFC] varobj deletion after the binary has changed

[Nick Roberts <nickrob@snap.net.nz>]

[-- Attachment #1: message body and .signature --]
[-- Type: text/plain, Size: 2320 bytes --]

 > > And what kind of problems does it cause, for the record? I'd expect that
 > > attempt of evaluating such expressions will result in value being "",
 > > and in_scope="false". Do you get anything worse than that?

It's a global variable so I don't think it will ever be reported as out
of scope.

 > Yes we are, gdb crashes.

This is a bug in GDB and how to deal with variable objects when restarting
should be a separate issue.  I see the same problem in a CVS snapshot of
6.2 vintage but not in GDB 6.3 from Fedora Core 5.  So unless the problem
disappeared in 6.3 and reasppeared later, which is unlikely, I think Fedora
must have solved it with one of their patches.  The problem is I don't know
which one.

I attach the SPEC file which lists the patches.  If anyone can give me an
educated guess as to which the relevant patch is, I'll try it.  Some of the
patches specify an architecture, but they may be more general than they
suggest.

In case it helps here's part of the stack at crash:

#0  0x081454e4 in check_typedef (type=0x95e1e6d) at gdbtypes.c:1402
#1  0x080f5769 in allocate_value (type=0x95e1e6d) at value.c:217
#2  0x080eca5d in read_var_value (var=0x95ee3f0, frame=0x0) at findvar.c:399
#3  0x080ffb3b in value_of_variable (var=0x95ee3f0, b=0x0) at valops.c:808
#4  0x080f88ef in evaluate_subexp_standard (expect_type=0x0, exp=0x95e9958, pos=0xbfdba084, noside=EVAL_NORMAL) at eval.c:480
#5  0x080f79f2 in evaluate_subexp (expect_type=0x0, exp=0x95e9958, pos=0xbfdba084, noside=EVAL_NORMAL) at eval.c:76
#6  0x080f7bc9 in evaluate_expression (exp=0x95e9958) at eval.c:166
#7  0x081a8613 in gdb_evaluate_expression (exp=0x95e9958, value=0xbfdba0e4) at wrapper.c:49
#8  0x081a7734 in c_value_of_root (var_handle=0xbfdba1e0) at varobj.c:2025
#9  0x081a6ede in value_of_root (var_handle=0xbfdba1e0, type_changed=0xbfdba17c) at varobj.c:1672
#10 0x081a6054 in varobj_update (varp=0xbfdba1e0, changelist=0xbfdba1c8) at varobj.c:1068

The crash occurs because computing TYPE_CODE (type) involves a memory
violation.  This comes from "type = SYMBOL_TYPE (var)" in read_var_value, in
turn from var = exp->elts[pc + 2].symbol which is from exp = var->root->exp of
the variable object in question (if that makes sense!).


-- 
Nick                                           http://www.inet.net.nz/~nickrob


[-- Attachment #2: SPEC file for FC5 GDB --]
[-- Type: application/octet-stream, Size: 18053 bytes --]