While trying to see if I could help out Jean, I found this piece of
documentation about libgc:
https://github.com/ivmai/bdwgc/blob/master/doc/debugging.md
BDWGC is the project name for libgc.so
Quoting from that page:
If the fault occurred in GC_find_limit, or with incremental collection
> enabled, this is probably normal. The collector installs handlers to take
> care of these. You will not see these unless you are using a debugger. Your
> debugger should allow you to continue. It's often preferable to tell the
> debugger to ignore SIGBUS and SIGSEGV ("handle SIGSEGV SIGBUS nostop
> noprint" in gdb, "ignore SIGSEGV SIGBUS" in most versions of dbx) and set a
> breakpoint in abort. The collector will call abort if the signal had
> another cause, and there was not other handler previously installed.
It's possible this will be enough for debugging our Guile-based
application. However, just in case the original page might move, there is a
second mechanism to try if the above proves unsuitable:
If the application generates an unhandled SIGSEGV or equivalent, it may
> often be easiest to set the environment variable GC_LOOP_ON_ABORT. On many
> platforms, this will cause the collector to loop in a handler when the
> SIGSEGV is encountered (or when the collector aborts for some other
> reason), and a debugger can then be attached to the looping process. This
> sidesteps common operating system problems related to incomplete core files
> for multi-threaded applications, etc.
I don't think lilypond requires this deeper level of trickery, but just in
case.
HTH,
Luca
On Wed, May 18, 2022 at 1:08 AM Jean Abou Samra <j...@abou-samra.fr> wrote:
>
>
> Le 17/05/2022 à 13:06, Jean Abou Samra a écrit :
> > Hi,
> >
> > After upgrading to Ubuntu 22.04 LTS, I can no longer use GDB
> > with LilyPond, although it runs fine outside of GDB.
> > [...]
>
>
> Thanks to private replies, I have learnt that this is apparently
> expected, and it works to type "continue" when this segfault
> appears.
>
>
>
--
Luca Fascione
