GNU bug report logs - #54056
guix-data-service build failure, segfault probably related to guile@3.0.8

Previous Next

To reply to this bug, email your comments to 54056 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: bug-guix <at> gnu.org
Subject: guix-data-service build failure, segfault probably related to
 guile <at> 3.0.8
Date: Fri, 18 Feb 2022 15:08:22 +0000

[Message part 1 (text/plain, inline)]

The recent derivation for the guix-data-service built with Guile 3.0.8
seems to often segfault when running the tests (see the failed builds
here [1]).

1: https://data.guix.gnu.org/gnu/store/qzxq38kpd2vrpj1xwgd5i3gjdkmmxmn1-guix-data-service-0.0.1-29.4a1088c.drv

With some help from IRC, I managed to get a core dump:

Core was generated by `/gnu/store/jjl6sa1bhjpj9cssi80yr4h8ihdgk34z-guile-3.0.8/bin/guile --no-auto-com'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007ffff0720496 in ?? ()
[Current thread is 1 (LWP 2505)]
(gdb) bt
#0  0x00007ffff0720496 in ?? ()
#1  0x0000000000436488 in ?? ()
#2  0x00007ffff19eb180 in ?? ()
#3  0x00007fffea6ac858 in ?? ()
#4  0x00007ffff7ee7ccc in scm_jit_enter_mcode (thread=0x7ffff75c8d80, mcode=0x439154 <incomplete sequence \340>) at jit.c:6038
#5  0x00007ffff7f3cf3c in vm_regular_engine (thread=0x7ffff75c8d80) at vm-engine.c:360
#6  0x00007ffff7f4a5e9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=4) at vm.c:1608
#7  0x00007ffff7eb2144 in scm_call_4 (proc=<optimized out>, arg1=<optimized out>, arg2=<optimized out>, arg3=<optimized out>, arg4=<optimized out>) at eval.c:517
#8  0x00007ffff7eaedd0 in error_during_backtrace (data=0x7ffff1c2b080, tag=out-of-range, throw_args=<error reading variable: ERROR: Cannot access memory at address 0x0>0x7fffe5a9bb80) at backtrace.c:252
#9  0x00007ffff7f68821 in scm_c_with_exception_handler.constprop.0 (type=#t, handler_data=handler_data <at> entry=0x7fffffff98b0, thunk_data=thunk_data <at> entry=0x7fffffff98b0, thunk=<optimized out>, handler=<optimized out>) at exceptions.c:167
#10 0x00007ffff7f3a88f in scm_c_catch (tag=<optimized out>, body=<optimized out>, body_data=<optimized out>, handler=<optimized out>, handler_data=<optimized out>, pre_unwind_handler=pre_unwind_handler <at> entry=0x0, pre_unwind_handler_data=0x0) at throw.c:168
#11 0x00007ffff7f3a8ae in scm_internal_catch (tag=<optimized out>, body=<optimized out>, body_data=<optimized out>, handler=<optimized out>, handler_data=<optimized out>) at throw.c:177
#12 0x00007ffff7eaf005 in scm_display_backtrace_with_highlights (stack=stack <at> entry="#<struct stack>" = {...}, port=port <at> entry=#<port #<port-type file 7ffff1bf3b40> 7ffff1c2b080>, first=first <at> entry=#f, depth=depth <at> entry=#f, highlights=highlights <at> entry=()) at backtrace.c:277
#13 0x00007ffff7eaf080 in scm_backtrace_with_highlights (highlights=()) at backtrace.c:310
#14 0x00007ffff7f3d336 in vm_regular_engine (thread=0x7ffff75c8d80) at vm-engine.c:972
#15 0x00007ffff7f4a5e9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=4) at vm.c:1608
#16 0x00007ffff7eb6571 in scm_apply_0 (proc=#<program 7ffff1c55700>, args=()) at eval.c:603
#17 0x00007ffff7f3bc8d in scm_throw (key=match-error, args=("match" "no matching pattern" x86_64-linux)) at throw.c:262
#18 0x00007ffff7edb239 in throw_ (key=<optimized out>, args=<optimized out>) at intrinsics.c:396
#19 0x00007ffff7f3f137 in vm_regular_engine (thread=0x7ffff75c8d80) at vm-engine.c:1183
#20 0x00007ffff7f4a5e9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=1) at vm.c:1608
#21 0x00007ffff7eb2457 in scm_primitive_eval (exp=<optimized out>) at eval.c:671
#22 0x00007ffff7eeb239 in scm_primitive_load (filename=filename <at> entry="/tmp/guix-build-guix-data-service-0.0.1-29.4a1088c.drv-0/source/tests/jobs-load-new-guix-revision.scm") at load.c:131
#23 0x00007ffff7eedff0 in scm_primitive_load_path (args=<optimized out>) at load.c:1267
#24 0x00007ffff7f3d336 in vm_regular_engine (thread=0x7ffff75c8d80) at vm-engine.c:972
#25 0x00007ffff7f4a5e9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=1) at vm.c:1608
#26 0x00007ffff7eb2457 in scm_primitive_eval (exp=<optimized out>, exp <at> entry=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang) "./build-aux/test-driver.scm") (main (command-line)) (quit)))) at eval.c:671
#27 0x00007ffff7eb84b6 in scm_eval (exp=((@ (ice-9 control) %) (begin ((@@ (ice-9 command-line) load/lang) "./build-aux/test-driver.scm") (main (command-line)) (quit))), module_or_state="#<struct module>" = {...}) at eval.c:705
#28 0x00007ffff7f1c3b6 in scm_shell (argc=19, argv=0x7fffffffa6d8) at script.c:357
#29 0x00007ffff7ec749c in invoke_main_func (body_data=0x7fffffffa590) at init.c:312
#30 0x00007ffff7eb085a in c_body (d=0x7fffffffa4b0) at continuations.c:430
#31 0x00007ffff7f3d336 in vm_regular_engine (thread=0x7ffff75c8d80) at vm-engine.c:972
#32 0x00007ffff7f4a5e9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=2) at vm.c:1608
#33 0x00007ffff7eb209a in scm_call_2 (proc=<optimized out>, arg1=<optimized out>, arg2=<optimized out>) at eval.c:503
#34 0x00007ffff7f68752 in scm_c_with_exception_handler.constprop.0 (type=#t, handler_data=handler_data <at> entry=0x7fffffffa440, thunk_data=thunk_data <at> entry=0x7fffffffa440, thunk=<optimized out>, handler=<optimized out>) at exceptions.c:170
#35 0x00007ffff7f3a88f in scm_c_catch (tag=<optimized out>, body=<optimized out>, body_data=<optimized out>, handler=<optimized out>, handler_data=<optimized out>, pre_unwind_handler=<optimized out>, pre_unwind_handler_data=0x7ffff1c2b040) at throw.c:168
#36 0x00007ffff7eb2e66 in scm_i_with_continuation_barrier (pre_unwind_handler=0x7ffff7eb2b80 <pre_unwind_handler>, pre_unwind_handler_data=0x7ffff1c2b040, handler_data=0x7fffffffa4b0, handler=0x7ffff7eb98b0 <c_handler>, body_data=0x7fffffffa4b0, body=0x7ffff7eb0850 <c_body>) at continuations.c:368
#37 scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized out>) at continuations.c:464
#38 0x00007ffff7f39b39 in with_guile (base=0x7fffffffa538, data=0x7fffffffa560) at threads.c:645
#39 0x00007ffff7e100ba in GC_call_with_stack_base () from /gnu/store/2lczkxbdbzh4gk7wh91bzrqrk7h5g1dl-libgc-8.0.4/lib/libgc.so.1
#40 0x00007ffff7f328b8 in scm_i_with_guile (dynamic_state=<optimized out>, data=<optimized out>, func=<optimized out>) at threads.c:688
#41 scm_with_guile (func=<optimized out>, data=<optimized out>) at threads.c:694
#42 0x00007ffff7ed0025 in scm_boot_guile (argc=argc <at> entry=19, argv=argv <at> entry=0x7fffffffa6d8, main_func=main_func <at> entry=0x401230 <inner_main>, closure=closure <at> entry=0x0) at init.c:295
#43 0x00000000004010f7 in main (argc=19, argv=0x7fffffffa6d8) at guile.c:94

[signature.asc (application/pgp-signature, inline)]

Message #8 received at 54056 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 54056 <at> debbugs.gnu.org
Subject: Re: bug#54056: guix-data-service build failure, segfault probably
 related to guile <at> 3.0.8
Date: Wed, 02 Mar 2022 17:11:51 +0100

Hi,

Christopher Baines <mail <at> cbaines.net> skribis:

> Core was generated by `/gnu/store/jjl6sa1bhjpj9cssi80yr4h8ihdgk34z-guile-3.0.8/bin/guile --no-auto-com'.
> Program terminated with signal SIGSEGV, Segmentation fault.

This segfault seems to come from a bug (an out-of-range exception is
raised) while walking the VM stack to display the backtrace:

> #8  0x00007ffff7eaedd0 in error_during_backtrace (data=0x7ffff1c2b080, tag=out-of-range, throw_args=<error reading variable: ERROR: Cannot access memory at address 0x0>0x7fffe5a9bb80) at backtrace.c:252
> #9  0x00007ffff7f68821 in scm_c_with_exception_handler.constprop.0 (type=#t, handler_data=handler_data <at> entry=0x7fffffff98b0, thunk_data=thunk_data <at> entry=0x7fffffff98b0, thunk=<optimized out>, handler=<optimized out>) at exceptions.c:167
> #10 0x00007ffff7f3a88f in scm_c_catch (tag=<optimized out>, body=<optimized out>, body_data=<optimized out>, handler=<optimized out>, handler_data=<optimized out>, pre_unwind_handler=pre_unwind_handler <at> entry=0x0, pre_unwind_handler_data=0x0) at throw.c:168
> #11 0x00007ffff7f3a8ae in scm_internal_catch (tag=<optimized out>, body=<optimized out>, body_data=<optimized out>, handler=<optimized out>, handler_data=<optimized out>) at throw.c:177
> #12 0x00007ffff7eaf005 in scm_display_backtrace_with_highlights (stack=stack <at> entry="#<struct stack>" = {...}, port=port <at> entry=#<port #<port-type file 7ffff1bf3b40> 7ffff1c2b080>, first=first <at> entry=#f, depth=depth <at> entry=#f, highlights=highlights <at> entry=()) at backtrace.c:277

(Of course, both the out-of-range exception and subsequent segfault are
genuine Guile bugs.)

The real cause of the error though seems to be a ‘match-error’ in
application code:

> #17 0x00007ffff7f3bc8d in scm_throw (key=match-error, args=("match" "no matching pattern" x86_64-linux)) at throw.c:262
> #18 0x00007ffff7edb239 in throw_ (key=<optimized out>, args=<optimized out>) at intrinsics.c:396
> #19 0x00007ffff7f3f137 in vm_regular_engine (thread=0x7ffff75c8d80) at vm-engine.c:1183
> #20 0x00007ffff7f4a5e9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=1) at vm.c:1608
> #21 0x00007ffff7eb2457 in scm_primitive_eval (exp=<optimized out>) at eval.c:671
> #22 0x00007ffff7eeb239 in scm_primitive_load (filename=filename <at> entry="/tmp/guix-build-guix-data-service-0.0.1-29.4a1088c.drv-0/source/tests/jobs-load-new-guix-revision.scm") at load.c:131

Thoughts?

Ludo’.

Message #11 received at 54056 <at> debbugs.gnu.org (full text, mbox):

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 54056 <at> debbugs.gnu.org
Subject: Re: bug#54056: guix-data-service build failure, segfault probably
 related to guile <at> 3.0.8
Date: Wed, 02 Mar 2022 19:32:44 +0000

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> The real cause of the error though seems to be a ‘match-error’ in
> application code:
>
>> #17 0x00007ffff7f3bc8d in scm_throw (key=match-error, args=("match" "no matching pattern" x86_64-linux)) at throw.c:262
>> #18 0x00007ffff7edb239 in throw_ (key=<optimized out>, args=<optimized out>) at intrinsics.c:396
>> #19 0x00007ffff7f3f137 in vm_regular_engine (thread=0x7ffff75c8d80) at vm-engine.c:1183
>> #20 0x00007ffff7f4a5e9 in scm_call_n (proc=<optimized out>, argv=<optimized out>, nargs=1) at vm.c:1608
>> #21 0x00007ffff7eb2457 in scm_primitive_eval (exp=<optimized out>) at eval.c:671
>> #22 0x00007ffff7eeb239 in scm_primitive_load
>> (filename=filename <at> entry="/tmp/guix-build-guix-data-service-0.0.1-29.4a1088c.drv-0/source/tests/jobs-load-new-guix-revision.scm")
>> at load.c:131
>
> Thoughts?

So these are the tests, so exceptions are sometimes intended. Although
in this case, while the test in question was still passing, the failure
it was testing the handling for wasn't happening as expected. I've fixed
this in [1].

1: https://git.savannah.gnu.org/cgit/guix/data-service.git/commit/?id=3a9079856742b4d97bc434837323ff02eb9d32c3

I haven't updated the Guix package yet, but maybe this change will help.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.