Index: [thread] [date] [subject] [author]
  From: Christoph Egger <Christoph_Egger@t-online.de>
  To  : Ville Hallik <Ville.Hallik@mail.ee>
  Date: Tue, 13 Jul 1999 10:34:57 +0200 (MEST)

Re: hacking methods to find out bugs

On Tue, 13 Jul 1999, Ville Hallik wrote:

> On Tue, 13 Jul 1999, Andrew Apted wrote:
> 
> > Christoph Egger writes:
> > 
> > >  On Mon, 12 Jul 1999, Andrew Apted wrote:
> > >  
> > >  > Or run in X and use gdb (hacking libgg so that it doesn't catch SIGSEGV
> > >  > and prevent a core dump).
> > >  
> > >  With "hacking a lib so that it doesn't catch SIGSEGV" you mean I should
> > >  fix the bug to find the bug?
> >  
> > Nah.  Normally on UNIX, a SIGSEGV signal will produce a core dump. 
> > The LibGG library (in the LibGII tarball) catches that signal (etc) so
> > that graphics can be restored sanely.  But this means no core dump.
> 
> But You can raise SIGSEGV again after cleanup and voila: coredump is here.
> This works at least for the following simple program under glibc2.1
> (core shows exactly the right crashpoint: *p = 'a'; ):
> 
> #include <stdio.h>
> #include <signal.h>
> 
> void crash( int sig ) {
>   fprintf( stderr, "SIGSEGV received\n" );
>   signal( SIGSEGV, SIG_DFL );
>   raise( sig );
> }
> 
> int main() {
>   char *p = NULL;  
>   fprintf( stderr, "Establishing signal handler\n" );
>   signal( SIGSEGV, crash );
>   fprintf( stderr, "Crashing program\n" );
>   *p = 'a';
>   fprintf( stderr, "This message will never be seen\n" );
>   return 0;
> }

Can you give an more common example that works under glibc2.0 too?

Christoph Egger
E-Mail: Christoph_Egger@t-online.de

Index: [thread] [date] [subject] [author]