This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 0/2] Demangler crash handler


Florian Weimer wrote:
> * Mark Kettenis:
> > Besides, any signal handler that does more than just setting a
> > flag is probably broken.  Did you verify that you only call
> > async-signal-safe functions in the signal handler code path?
> 
> At least it doesn't make things much worse because the program is
> already in a funny state when the signal is generated.

Yes.  I'm not aiming for perfection, I was merely looking for simple
ways to get some protection from the kind of crashes I've observed.

> It would be more reliable to run the demangler in a separate
> process.

Agreed.  There are two issues though.  First is performance:
GDB can demangle a lot of symbols--starting GDB on LibreOffice
demangles more than 369,000 symbols on my machine, and typing
"b <Tab><Tab>" demangles 2,740,000 more--so the IPC overhead
has to be seriously low.

The second issue is my time.  I could spare the time to write
a simple, low-LOC patch like this, but if the only acceptable
solution is the demangler in a separate process then that has
to be way down my priority list--especially given that that
solution would likely be rejected on performance grounds.
I'm pretty sure there are people on this list for whom any
loss of performance would be unacceptable.

> What's so difficult about fixing the demangler?

It's not so difficult really, but fixes take time to diagnose,
reproduce, fix, test, review, etc.  During that interval the user
cannot use GDB to debug their program.  This patch is about
allowing the user the possibility of getting their work done.

Cheers,
Gary

-- 
http://gbenson.net/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]