Re: [patch] Fix for varobj.c assertions.

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jan 16, 2008 at 11:19:26AM +1300, Nick Roberts wrote:
> Maybe it cures the symptom and not the cause.  We really need to know what is
> happening here.  In your oringinal report the failed assertion occurred in
> my_value_equal but that function has gone now.  Presumably it now occurs in
> install_new_value, but at which line?
> 
> When there is no problem, presumably *value (in adjust_value_for_child_access)
> or value (in c_describe_child) are null.  How do they become non null for
> inaccessible memory in the failing case?

I can reproduce this too.  With GDB 6.7.1:

~"/tmp/buildd/gdb-6.7.1/gdb/varobj.c:2011: internal-error:
value_struct_element_index: Assertion `TYPE_CODE (type) ==
TYPE_CODE_STRUCT || TYPE_CODE (type) == TYPE_CODE_UNION' failed.\n"
~"A problem internal to GDB has been detected,\n"
~"further debugging may prove unreliable.\n"
~"Quit this debugging session? (y or n) "

With HEAD it's on line 2008, but otherwise the same.  type is a
pointer type, "B *".  *value was a B * value; indirecting it failed
because the pointer hasn't been initialized yet at the start of main.
When gdb_value_ind returns zero, it has not changed *result.  So we
go ahead as if *result was set.

Aleksandar's change to c_describe_child is safe but not necessary,
because *cvalue will already be NULL if gdb_value_ind fails.  The
change to adjust_value_for_child_access is right, and fixes the bug.
And the change to cplus_describe_child is definitely right (*whoops*).

So I've checked in the patch.

-- 
Daniel Jacobowitz
CodeSourcery