Re: Hanlding SIGSEGV/SIGBUG with glibc 2.3.2

[Yair Lenga]

Hi,

Since I can not do anything usefull in the signal handler (in praticular 
- cleanup) - can I use threads for the cleanup. I currently do not use 
threads in my code but from browsing in the man pages, it looks to me 
that I should be able to do the cleanup in a separate thread (assuming 
that the memory has not been corrupted). I'm thinking about:

pthread_t main_thread ;
int   done_ok ;

main() {
   main_thread = pthread_self() ;
   pthread_create (..., monitor_main, ...)
   ... actual code here ...
   cleanup()
   exit()
}

cleanup {
   if ( need_cleanup ) {
      need_clenaup = 0
      ... Actual Cleanup ...
   }

monitor_main {
   pthread_join(main_thread)
   cleanup()
}

Thanks for you inputs,

Yair

Wolfram Gloger wrote:

> Hello,
>
> > The problem can be replicated for many signals, and in
> > general the sequence is:
> >
> >     * The program is calling free
> >     * Free is locking the arena, call int_free to free the memory
> >     * Signal is recieved
> >     * the signal handler is invoked, trying to call
> >       free/malloc/vfork/... as part of the cleanup
>
> You _can't_ call free or malloc in a signal handler and expect it to
> work.  You _can_ call vfork/exec.
>
> >     * The process is trying to lock the arena - and get into 
> infinite wait.
> >
> > The documentation is very clear that the signal handler should not do
> > anything, but to flag the error condition, and return -
>
> Indeed, the signal handler _must not_ call anything but
> async-signal-safe functions.
>
> > I hope that other people have some experience and/or ideas on how to
> > deal with SIGSEGV (and similar) signals.
>
> After SIGSEGV, all bets are off -- you can really only perform a
> fork/exec to get to a clean state.  Maybe you should consider writing
> a small helper app that gets exec()ed in this case.
>
> Regards,
> Wolfram.