Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@broadcom.com>
To: Gary Benson <gbenson@redhat.com>,
	Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: <gdb-patches@sourceware.org>, <xdje42@gmail.com>, <eliz@gnu.org>,
	<fw@deneb.enyo.de>, <palves@redhat.com>, <tromey@redhat.com>
Subject: Re: [PATCH 0/2 v3] Demangler crash handler
Date: Wed, 04 Jun 2014 14:54:00 -0000	[thread overview]
Message-ID: <538F3300.6010700@broadcom.com> (raw)
In-Reply-To: <20140604133413.GA10121@blade.nx>

On 04/06/2014 2:34 PM, Gary Benson wrote:
> Mark Kettenis wrote:
>>> From: Gary Benson <gbenson@redhat.com>
>>> Is this ok to commit?
>>
>> Not for me.  You're running too much code between entering the
>> SIGSEGV handler and dumping core for my taste.
> 
> I don't understand.  This is the signal handler:
> 
>   static void
>   gdb_demangle_signal_handler (int signo)
>   {
>     static int core_dumped = 0;
>   
>     if (!core_dumped)
>       {
>         if (fork () == 0)
>           dump_core ();
>   
>         core_dumped = 1;
>       }
>   
>     SIGLONGJMP (gdb_demangle_jmp_buf, signo);
>   }
> 
> and this is dump_core:
> 
>   void
>   dump_core (void)
>   {
>   #ifdef HAVE_SETRLIMIT
>     struct rlimit rlim = { RLIM_INFINITY, RLIM_INFINITY };
>   
>     setrlimit (RLIMIT_CORE, &rlim);
>   #endif /* HAVE_SETRLIMIT */
>   
>     abort ();	/* NOTE: GDB has only three calls to abort().  */
>   }
> 
> This is what happens:
> 
>   1. the signal handler is entered
>   2. fork
>   3. setrlimit
>   4. abort
> 
> I could remove the setrlimit but presumably somebody added that to
> make a successful core dump more likely.
> 
> Would you accept this patch if I changed the dump_core to abort
> in gdb_demangle_signal_handler?  (and updated all the comments
> about having only three calls to abort)?
> 
>> I still very much agree with Pedro; this should not be necessary.
> 
> "Should" is the operative word here.  It *should* not be necessary
> because the demangler *should* never crash.  But this isn't utopia.
> The demangler is code, and code has bugs.  People make mistakes.
> Things are valid now that may not be valid in the future.  And GDB
> should not just crash if some symbol in the inferior isn't handled
> or doesn't make sense or whatever.

By this logic should / would we not extend the SIGSEGV handler to cover
all gdb code?  If the target is running in synchronous mode we'd
install our SEGV handler when the target stops and remove it when the
target restarts (asynchronous mode would need more thought), then any
bugs in gdb that cause a SEGV would result in a core dump ...

I'm just not sure why the demangler should get special treatment.

Thanks,
Andrew


  reply	other threads:[~2014-06-04 14:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-04 10:08 Gary Benson
2014-06-04 10:09 ` [PATCH 1/2 v3] Add new internal problem for demangler warnings Gary Benson
2014-06-04 10:18   ` Eli Zaretskii
2014-06-04 13:34     ` Gary Benson
2014-06-04 10:10 ` [PATCH 2/2 v3] Demangler crash handler Gary Benson
2014-06-04 10:20   ` Eli Zaretskii
2014-06-04 13:36     ` Gary Benson
2014-06-04 13:41       ` Eli Zaretskii
2014-06-04 14:28         ` Gary Benson
2014-06-04 15:24           ` Doug Evans
2014-06-04 18:25             ` Gary Benson
2014-06-05  1:11               ` Doug Evans
2014-06-05  2:54                 ` Eli Zaretskii
2014-06-04 16:05   ` Doug Evans
2014-06-04 18:34     ` Gary Benson
2014-06-04 10:21 ` [PATCH 0/2 " Eli Zaretskii
2014-06-04 13:41   ` Gary Benson
2014-06-04 13:49     ` Eli Zaretskii
2014-06-04 14:28       ` Gary Benson
2014-06-04 10:28 ` Mark Kettenis
2014-06-04 13:34   ` Gary Benson
2014-06-04 14:54     ` Andrew Burgess [this message]
2014-06-04 15:52       ` Doug Evans
2014-06-04 15:57       ` Gary Benson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=538F3300.6010700@broadcom.com \
    --to=aburgess@broadcom.com \
    --cc=eliz@gnu.org \
    --cc=fw@deneb.enyo.de \
    --cc=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=palves@redhat.com \
    --cc=tromey@redhat.com \
    --cc=xdje42@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox