Subject: bug#58923: closed (Re: bug#58923: Malformed core dumps on Guix System)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 10 Nov 2022 17:16:02 +0000

Your bug report

#58923: Malformed core dumps on Guix System

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
58923: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58923
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#58923: Malformed core dumps on Guix System
From: Mathieu Othacehe <[email-masked]>
To: Ludovic Courtès <[email-masked]>
Cc: [email-masked]
Date: Thu, 10 Nov 2022 18:14:59 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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

Subject: Malformed core dumps on Guix System
From: Mathieu Othacehe <[email-masked]>
To: [email-masked]
Date: Mon, 31 Oct 2022 11:23:48 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Hello,

Working on https://issues.guix.gnu.org/58733, I noticed that there is
something wrong with the core dumps we are generating on Guix System.

--8<---------------cut here---------------start------------->8---
mathieu@meije ~/tmp [env]$ cat test.c 
#include <stdio.h>
int main() {
	int *t = NULL;
	return *t;
}

mathieu@meije ~/tmp [env]$ gcc test.c 
mathieu@meije ~/tmp [env]$ ulimit -c unlimited
mathieu@meije ~/tmp [env]$ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited

mathieu@meije ~/tmp [env]$ echo "/tmp/my-core-%p" | sudo tee /proc/sys/kernel/core_pattern
/tmp/my-core-%p

mathieu@meije ~/tmp [env]$ ./a.out 
Segmentation fault (core dumped)

mathieu@meije ~/tmp [env]$ gdb ./a.out /tmp/my-core-5622
...
BFD: warning: /tmp/my-core-5622 has a segment extending past end of file
...
Failed to read a valid object file image from memory.
Core was generated by `./a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000000401102 in main ()
(gdb) bt
#0  0x0000000000401102 in main ()
Backtrace stopped: Cannot access memory at address 0x7fff14e14168
--8<---------------cut here---------------end--------------->8---

The "has a segment extending past end of file" warning appears to be
problematic and the "bt" command does not work which makes core dump
generation a bit useless.

Thanks,

Mathieu