[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GDB giving immediate segfault on LilyPond startup?
From: |
Luca Fascione |
Subject: |
Re: GDB giving immediate segfault on LilyPond startup? |
Date: |
Wed, 18 May 2022 22:21:13 +0200 |
On Wed, May 18, 2022 at 9:59 PM Jean Abou Samra <jean@abou-samra.fr> wrote:
> Le 18/05/2022 à 13:54, Luca Fascione a écrit :
> >
> > Quoting from that page:
> > [...]
> > The collector will call abort if the signal
> > had another cause, and there was not other handler previously
> > installed.
> >
>
> That did prevent GDB from stopping on startup with SIGSEGV, but
> it also prevented it from halting when the segfault I was actually
> interested in was encountered.
>
If that's the case, the breakpoint you put in the collector, where it calls
abort, is not triggering.
One way to set up that breakpoint is:
- use the 'continue' method you discovered and run your program
- let it crash in your code
- go up a frame or two, until you're in the frame that calls 'abort()',
which is in the signal handler code of libgc, and set a breakpoint there (*)
- call the commands above that make SIGSEGV quiet
- call 'run ...' again (GDB will say 'should I restart the prg
completely?', and you'll go: "yeah sure". The breakpoints stay where you
had them)
Now it'll trigger the breakpoint at the real SIGSEGV, and you can go up
your stack a few frames and see what's going on.
Profit.
(*) this position in the code will not move, so it might be worth
documenting it in lilypond's debugging procedure manual,
libgc appears to be a very stable piece of code at this point.
HTH,
L
--
Luca Fascione