bug#58923: Malformed core dumps on Guix System

[Mathieu Othacehe]

Hey,

Thanks for trying to reproduce it. Turns out, it is now working both on
Berlin and on installation images but still failing on my machine. It's
not often that those kind of issues do resolve by themselves. I would
suspect a kernel regression here.

My machine has the following kernel:
Linux meije 5.19.15 #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux 

while Berlin and installation images have respectively:
Linux berlin.guix.gnu.org 6.0.7-gnu #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux
Linux gnu 6.0.7-gnu #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux

Anyway, we can now:

--8<---------------cut here---------------start------------->8---
wget https://dump.guix.gnu.org/download/installer-dump-1c97b34e
tar -xvf installer-dump-1c97b34e
cd dump.2022-10-14.17.15.30
gdb $(type -P guile) core-dump
(gdb) bt
#0  linux_destroy (dev=0x268e620) at arch/linux.c:1615
#1  0x00007fee6ae9cd37 in chained_finalizer (obj=0x7fee54779370, 
data=0x7fee6790acc0) at finalizers.c:84
#2  0x00007fee6adf5e3f in GC_invoke_finalizers () at extra/../finalize.c:1281
#3  0x00007fee6ae9d429 in scm_run_finalizers () at finalizers.c:414
#4  0x00007fee6aea4482 in finalization_thread_proc (unused=<optimized out>) at 
finalizers.c:244
#5  0x00007fee6ae9085a in c_body (d=0x7fee69f21d80) at continuations.c:430
#6  0x00007fee6af1d326 in vm_regular_engine (thread=0x7fee6a3b8b40) at 
vm-engine.c:972
#7  0x00007fee6af2a5d9 in scm_call_n (proc=<optimized out>, argv=<optimized 
out>, nargs=2) at vm.c:1610
#8  0x00007fee6ae9209a in scm_call_2 (proc=<optimized out>, arg1=<optimized 
out>, arg2=<optimized out>) at eval.c:503
#9  0x00007fee6af48742 in scm_c_with_exception_handler.constprop.0 (type=#t, 
handler_data=handler_data@entry=0x7fee69f21d10, 
thunk_data=thunk_data@entry=0x7fee69f21d10, thunk=<optimized out>, 
handler=<optimized out>)
    at exceptions.c:170
#10 0x00007fee6af1a88f 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=0x7fee6a436040) at throw.c:168
#11 0x00007fee6ae92e66 in scm_i_with_continuation_barrier 
(pre_unwind_handler=0x7fee6ae92b80 <pre_unwind_handler>, 
pre_unwind_handler_data=0x7fee6a436040, handler_data=0x7fee69f21d80, 
handler=0x7fee6ae998b0 <c_handler>, 
    body_data=0x7fee69f21d80, body=0x7fee6ae90850 <c_body>) at 
continuations.c:368
#12 scm_c_with_continuation_barrier (func=<optimized out>, data=<optimized 
out>) at continuations.c:464
#13 0x00007fee6af19b39 in with_guile (base=0x7fee69f21e08, data=0x7fee69f21e30) 
at threads.c:645
#14 0x00007fee6adf00ba in GC_call_with_stack_base (fn=fn@entry=0x7fee6af19a60 
<with_guile>, arg=arg@entry=0x7fee69f21e30) at extra/../misc.c:2106
#15 0x00007fee6af128b8 in scm_i_with_guile (dynamic_state=<optimized out>, 
data=<optimized out>, func=<optimized out>) at threads.c:688
#16 scm_with_guile (func=<optimized out>, data=<optimized out>) at threads.c:694
#17 0x00007fee6adc6d7e in ?? () from 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libpthread.so.0
#18 0x00007fee6a9c4eff in clone () from 
/gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/libc.so.6
--8<---------------cut here---------------end--------------->8---

which feels quite nice.

Closing that one.

Thanks,

Mathieu