Re: [PATCH] Make interrupting tab-completion safe.

[Sterling Augustine <saugustine@google.com>]

On Sun, Jun 12, 2011 at 5:11 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Sat, 11 Jun 2011 02:19:05 +0200, Sterling Augustine wrote:
>> gdb <really big program>
>> b <tab><tab>
>> [ctrl-c before tab-completion is done]
>> b <tab>
>> (segmentation fault)
>
> I do not have it reproducuble, does not happen for you for ./gdb -nx ./gdb?
> Tried also Firefox, both processing runs long enough to CTRL-C it.

gdb itself isn't big enough to make it easy to reproduce (~24k
symbols). The smallest programs I see this on are about 5x that size
and don't use shared libraries. (Not sure about mozilla, or the
interaction between shared libraries and this.) Certainly, the bigger
the binary, the easier it is to reproduce. If you haven't noticed that
tab-completion (immediately on launch with no init script) is unusably
slow, then the binary probably isn't big enough to trip this bug
easily.

The race is between the conversion from psymtab to full symtab and you
hitting ctrl-c. Some of this time is also spent handling filename
completion, which doesn't have the problem. You need to be sure to
interrupt c_type_print_args, when called from dwarf2read.c:5049.

> It would be good to have a testcase for regressions anyway.

Is there an existing test-case I can model this one on? (One that
sends an asynchronous sigint to gdb is probably enough.) I can't seem
to find any, but my deja-gnu foo is weak.

>> The problem comes because the dwarf2read.c tries to discover the full
>> linkage name of symbols, and assumes that it won't be interrupted.
>
> I had rather an idea to make it interruption-safe as this way another
> forgotten or newly introduced QUIT may regression it.  But I do not have
> a reproducer to check where the crash happens.