Re: [patch] Fix a crash when displaying variables from shared library.

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Thu, Mar 5, 2009 at 3:46 PM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:

> Attached is the patch I just committed.

While back-porting this fix into our GDB-6.8, I discovered that this part:

+	  if (block != NULL
+	      && solib_address (block->startaddr) == solib->so_name)

will never work, because in clear_solib:

      so_list_head = so->next;
      observer_notify_solib_unloaded (so);

and solib_address uses so_list_head to search for matching address.
[Aren't ordering issues fun :-[

So I reversed the order:

      observer_notify_solib_unloaded (so);
      so_list_head = so->next;

only to discover that this causes

  FAIL: gdb.base/attach.exp: attach1 detach

because:

  warning: Temporarily disabling breakpoints for unloaded shared
library "/lib64/ld-linux-x86-64.so.2"

Why wasn't this breakpoint shlib_disabled in disable_breakpoints_in_shlibs()
just a couple of lines above?

Because it's of the wrong type (bp_shlib_event), and
disable_breakpoints_in_shlibs() only disables bp_breakpoint and
bp_hardware_breakpoint.

I am not sure whether:
A) bp_shlib_event type breakpoints should also be shlib_disable'd, or
B) disable_breakpoints_in_unloaded_shlib() should only warn about
   bp_breakpoint and bp_hardware_breakpoint type, or
C) the call to "solib_address (block->startaddr)" should be replaced with
   something like "solib_contains_p (solib, block->startaddr)" (which would
   then work independently of the so_list_head).

Advice?

(C) is the least disruptive; (A) appears to be logical (but I don't know
whether it will break anything); (B) looks like a hack to me.

Thanks,
-- 
Paul Pluzhnikov