Ludovic Courtès <l...@gnu.org> skribis:
> 1.0.9 seems to help my rather involved use case (Guix cross-compiled to
> GNU/Hurd from x86_64-linux, then running ‘guix pull’, which depends on
> Guile-Git, which uses Bytestructures) but it still eventually crashes:
>
> ludo@childhurd ~$
> /gnu/store/mxi1za8gdq77438ywgzdzy2zywb9nk76-guix-1.2.0rc1-1.3ba6ffd/bin/guix
> pull
> Updating channel 'guix' from Git repository at
> 'https://git.savannah.gnu.org/git/guix.git'...
> receiving objects 25% [#############
> ]Illegal instruction
Most likely, this crash is due to the use of new progress report feature
in (guix git). If I arrange to not use it, clone the whole repo
proceeds without crashing.
Unfortunately I’m unable to get a usable backtrace once SIGILL has been
raised, be it by attaching to it (using
CRASHSERVER=/servers/crash-suspend), spawning it and crashing it from
gdb, or inspecting its core file. At best I can see the backtrace of
the msg thread, nothing more:
--8<---------------cut here---------------start------------->8---
(gdb) thread 1
[Switching to thread 1 (process 310)]
#0 0x080f08c0 in ?? ()
(gdb) bt
#0 0x080f08c0 in ?? ()
#1 0x00000000 in ?? ()
(gdb) thread 2
[Switching to thread 2 (process 1)]
#0 0x0159282c in mach_msg_trap () at
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.31.drv-0/build/mach/mach_msg_trap.S:2
2
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.31.drv-0/build/mach/mach_msg_trap.S:
No such file or directory.
(gdb) bt
#0 0x0159282c in mach_msg_trap () at
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.31.drv-0/build/mach/mach_msg_trap.S:2
#1 0x01592f2a in __GI___mach_msg (msg=0x2802aa0, option=3, send_size=96,
rcv_size=32, rcv_name=109, timeout=0, notify=0) at msg.c:111
#2 0x017dc8ab in __crash_dump_task (crashserver=132, task=1, file=133,
signo=11, sigcode=2, sigerror=2, exc=1, code=2, subcode=210986494,
cttyid_port=102, cttyid_portPoly=19)
at
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.31.drv-0/build/hurd/RPC_crash_dump_task.c:254
#3 0x015b248c in write_corefile (detail=<optimized out>, signo=<optimized
out>) at hurdsig.c:296
#4 post_signal (untraced=<optimized out>) at hurdsig.c:947
#5 0x015b274b in _hurd_internal_post_signal (ss=0x1800808, signo=11,
detail=0x2802e5c, reply_port=0, reply_port_type=17, untraced=0) at
hurdsig.c:1235
#6 0x015b3fc1 in _S_catch_exception_raise (port=96, thread=39, task=1,
exception=1, code=2, subcode=210986494) at catch-exc.c:88
#7 0x017c09b4 in _Xexception_raise (InHeadP=0x2802f20, OutHeadP=0x2803f30) at
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.31.drv-0/build/mach/mach/exc_server.c:155
#8 0x017c0a52 in _S_exc_server (InHeadP=0x2802f20, OutHeadP=0x2803f30) at
/tmp/guix-build-glibc-cross-i586-pc-gnu-2.31.drv-0/build/mach/mach/exc_server.c:208
#9 0x015a7a09 in msgport_server (inp=0x2802f20, outp=0x2803f30) at
msgportdemux.c:49
#10 0x015934c3 in __mach_msg_server_timeout (demux=0x15a79b0 <msgport_server>,
max_size=4096, rcv_name=96, option=0, timeout=0) at msgserver.c:108
#11 0x01593607 in __mach_msg_server (demux=0x15a79b0 <msgport_server>,
max_size=4096, rcv_name=96) at msgserver.c:195
#12 0x015a7a86 in _hurd_msgport_receive () at msgportdemux.c:67
#13 0x011eda50 in entry_point (self=0x804ac20, start_routine=0x15a7a30
<_hurd_msgport_receive>, arg=0x0) at pt-create.c:62
#14 0x00000000 in ?? ()
--8<---------------cut here---------------end--------------->8---
(Would be nice to fix this debugging issue. It looks like GDB fails to
interpret the thread state of suspended threads or something.)
Anyway, this crash could be due to a GC issue, in which case it would
not be Hurd-specific. I could not reproduce it with i686-linux ‘guix’
though, and obviously not with x86_64 binaries either.
Ludo’.
