On 04/27/2015 11:46 PM, Vladimir Prus wrote:
thanks, so the issue is that removing a symbol file recreates
*all* global varobjs, and in the process clears any change of value
since the last update. I agree the patch is fixing that.
There's a second change, it seems - to invalidate varobj that refers
to types in unloaded objfile - is there a test for that?
Hi Vladimir,
Sorry for delayed response. There are no separate tests for invalidation
of varobjs in unloaded objfile as it gets tested by existing varobj
tests. If we don't invalidate varobjs in unloaded objfile, a lot GDB
tests will fail. This is because while trying to retrieve old varobj
value for already removed objfile (to compare with current value), it
will try to access pointers that are no longer valid and that will
result in failure.
Marking varobjs that refers to types in unloaded objfile invalid makes
sure we do not accidentally use dangling pointers to obtain varobj value
for unloaded objfile.
IMO, GDB should avoid using pointers whose target has been already freed
and this change specifically marks var->type to NULL to make sure no
dangling pointers remain after objfile is unloaded so any subsequent
call to varobj_get_value does not result in segmentation fault.
Thanks,
Taimoor