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

[Paul Pluzhnikov <ppluzhnikov@google.com>]

On Mon, Feb 23, 2009 at 10:12 AM, Paul Pluzhnikov
<ppluzhnikov@google.com> wrote:

> On Sun, Feb 22, 2009 at 5:07 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>>> +  for (i = 0; i < d->exp->nelts; i++)
>>> +    {
>>> +      union exp_element *elts = d->exp->elts;
>>> +      if (elts[i].opcode == OP_VAR_VALUE)
>>
>> I'm afraid this isn't going to work for more complex structures...
>> The problem is that you might be reading an undefined field of
>> union exp_element. Imagine for instance that you have an expression
>> that looks like this: "foo->bar".
>>
>> At one point, you'll encounter the following elements:
>>
>>   [i  ]  ->  STRUCTOP_PTR
>>   [i+1]  ->  A string
>>   [i+2]  ->  STRUCTOP_PTR
>>
>> Iterating over the expression, you'll ignore the element at index i,
>> and then check the opcode of the element at i+1, which is the wrong
>> field of the enum to access in this case...
>
> I was afraid of that ...

So I just discovered operator_length_standard, which lets me rewrite
this loop and avoid this problem:

  for (i = 0; i < d->exp->nelts; )
    {
      union exp_element *elts = d->exp->elts;
      int oplen, args;
      if (elts[i].opcode == OP_VAR_VALUE)
	{
	  struct block *block = elts[i + 1].block;
	  struct symbol *symbol = elts[i + 2].symbol;
	  struct obj_section *section;

	  gdb_assert (elts[i + 3].opcode == OP_VAR_VALUE);

	  if (block)
	    {
	      const char *const solib_name = solib_address(block->startaddr);
	      if (solib_name && strcmp(solib_name, solib->so_name) == 0)
		return 1;
	    }

	  section = SYMBOL_OBJ_SECTION (symbol);
	  if (section && section->objfile == solib->objfile)
	    return 1;
	}
      operator_length_standard (d->exp, i + 1, &oplen, &args);
      i += oplen;
    }

I think this will correctly iterate over all elements of the
expression, will it not?

Unfortunately, this code still crashes, because no_shared_libraries
first calls objfile_purge_solibs (which indirectly does
obstack_free), and only then clear_solib, which notifies me that
the library has already disappeared. When I proceed to use symbol,
I am already using dangling obstack :-(

Is it ok to move observer notification to before objfile_purge_solibs,
or should I add a new notification? Something like:

  @deftypefun void solib_about_to_be_unloaded (struct so_list *@var{solib})
  The shared library specified by @var{solib} is about to be unloaded.
  @end deftypefun

Thanks,
-- 
Paul Pluzhnikov