This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Fix a crash when displaying variables from shared library.
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: Joel Brobecker <brobecker at adacore dot com>
- Cc: Tom Tromey <tromey at redhat dot com>, Pedro Alves <pedro at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Mon, 2 Mar 2009 18:30:59 -0800
- Subject: Re: [patch] Fix a crash when displaying variables from shared library.
- References: <20090205030257.8A6073A6B7A@localhost> <m3wsc3459t.fsf@fleche.redhat.com> <8ac60eac0902061837p5885b812j8a26669e799702e1@mail.gmail.com> <m3y6wdrbn1.fsf@fleche.redhat.com> <8ac60eac0902181458g39dfbce9k63c3329528b0aad5@mail.gmail.com> <20090223010759.GA30997@adacore.com> <8ac60eac0902231012lb42bcb1q8b8cf19ad2ac192@mail.gmail.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