emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: GNU bug Tracking System
Subject: bug#58923: closed (Malformed core dumps on Guix System)
Date: Thu, 10 Nov 2022 17:16:02 +0000

Your message dated Thu, 10 Nov 2022 18:14:59 +0100
with message-id <87bkpezq7g.fsf@gnu.org>
and subject line Re: bug#58923: Malformed core dumps on Guix System
has caused the debbugs.gnu.org bug report #58923,
regarding Malformed core dumps on Guix System
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
58923: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58923
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: Malformed core dumps on Guix System Date: Mon, 31 Oct 2022 11:23:48 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
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



--- End Message ---
--- Begin Message --- Subject: Re: bug#58923: Malformed core dumps on Guix System Date: Thu, 10 Nov 2022 18:14:59 +0100 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]