bug-guix
[Top][All Lists]
Advanced

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

bug#44000: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures w


From: Ludovic Courtès
Subject: bug#44000: Guile-Git cross-compiled to i586-pc-gnu gets bytestructures wrong
Date: Mon, 16 Nov 2020 23:01:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Ludovic Courtès <ludo@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’.





reply via email to

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