This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix for varobj.c assertions.
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