Re: collecting data from a coring process

[Samuel Bronson <naesten@gmail.com>]

On Tue, Sep 6, 2016 at 12:40 PM, Paul Marquess
<Paul.Marquess@owmobility.com> wrote:
> From: Samuel Bronson [mailto:naesten@gmail.com]
>
>
>> On Mon, Sep 5, 2016 at 7:19 PM, Paul Marquess <Paul.Marquess@owmobility.com> wrote:
>> > From: Samuel Bronson [mailto:naesten@gmail.com]
>> >
>> >> On Mon, Sep 5, 2016 at 7:09 AM, Paul Marquess <Paul.Marquess@owmobility.com> wrote:
>> >> > From: Dmitry Samersoff [mailto:dms@samersoff.net]
>> >> >
>> >> >> Paul,
>> >> >>
>> >> >> >> 1) Why not dump the information that you are looking for into a
>> >> >> >> file in the process signal handler ?
>> >> >> >
>> >> >> > Would love to, but I have no idea what state the process is in
>> >> >> > once the SEGV has been triggered.
>> >> [...]
>> >> > I know we've had problems with signal handlers causing problems, thus my preference to find a way to have the signal handler code do as little as possible and get all the data collection handled at arm's length by gdb.
>> >>
>> >> You could just spawn (and wait for) your GDB-launching script from
>> >> the signal handler; then, the process & stack will still be around for GDB.  I think this is even legal!
>> >
>> > That's one of the approaches I'm thinking of. I need to check if the fork/exec & wait use malloc.
>>
>> I think it should suffice for them to be "async-signal-safe "?  It looks like signal(7) documents which functions several
>> versions of POSIX require to be async-signal-safe, and it looks like there are two versions of exec*() on there as well
>> as fork() and wait().  Which is basically what I meant by "I think this is even legal!" :-).
>
> I agree that "async-signal-safe " is something that needs to be considered, but it isn't the only thing. I've seen plenty of cores where corruption of a data structure inside malloc itself was the trigger for the SEGV. That's why I need to be sure that any code executed in the signal handler isn't going to blow up.

Hmm.  I had not really considered that it might technically be
possible to have an async-signal-safe implementation of malloc(), and
was therefore operating under the assumption that it was impossible
for an async-signal-safe function to rely on malloc().  So, that
leaves a few questions:

  1. Would it actually be a problem for an sync-signal-safe
implementation of malloc() to be called in this scenario?

  2. Is such an implementation even possible?

  3. Are you willing to take the chance that anyone would actually
ship one AND dare to use it in any of POSIX's mandated
async-signal-safe functions?

(Also, it has come to my attention that s*printf() are actually
functions which are not on the list -- somehow, the nature of their
task had gotten them past my radar -- so it's presumably simplest to
have the helper script get the parent PID on its own, rather than
passing it on the command line as I had initially imagined.)