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]