Schlagwort-Archive: YASM

Gentoo dev-lang/yasm-1.2.0-r1: Segfault während compile

Narf? Segfault bei der Gentoo-Grundinstallation? Unschön. Verursacher ist dev-lang/yasm-1.2.0-r1, welches irgendwo als dependency gezogen wurde. Der Code ist dabei nicht sehr hilfreich:

built perfect hash table of size 512
./re2c -b -o gas-token.c ./modules/parsers/gas/gas-token.re
./re2c -b -o nasm-token.c ./modules/parsers/nasm/nasm-token.re
Makefile:4780: recipe for target 'gas-token.c' failed
make: *** [gas-token.c] Segmentation fault
make: *** Deleting file 'gas-token.c'
make: *** Waiting for unfinished jobs....
Makefile:4783: recipe for target 'nasm-token.c' failed
make: *** [nasm-token.c] Segmentation fault
make: *** Deleting file 'nasm-token.c'

Auch dmesg macht nicht viel schlauer:

[*] re2c[*]: segfault at 0 ip 00007f3cc90441d0 sp 00007fffaa8fdee0 error 4 in libc-2.20.so[7f3cc8fda000+18e000]
[*] re2c[*]: segfault at 0 ip 00007ff5681921d0 sp 00007ffccd9b4300 error 4 in libc-2.20.so[7ff568128000+18e000]

Libc sollte funktionieren, alle anderen Pakete zeigten keine Fehler, aber zur Sicherheit mal neu kompilieren: Keine Änderung. Auch mein Versuch die als unstable markierte Version dev-lang/yasm-1.3.0 zu verwenden wirft die gleiche Meldung. Müssen wir wohl tiefer rein.

Erster Schritt: Handarbeit. Im passenden Ordner unter /var/tmp/Portage führe ich make selbst aus – kein Fehler. Schlecht, denn ein Fehler den man nicht reproduzieren kann, kann man auch nur schwer beheben. Also anderer Weg: In /usr/portage/dev-lang/yasm finden sich die passenden ebuilds – mit ebuild *1.2.0* compile lässt sich der Vorgang starten, mit anderen Befehlen am Ende auch selektiv einzelne Schritte durchführen. Treffer, hier tritt der Fehler auch auf. Nachdem spielen mit der make.conf (Stichwort CFLAGS, USE, …) keine Bessung zeigte bleibt dann nur ein Blick ins Innere. re2c wird aus eigenen Quellen gebaut und ist nicht mit dev-util/re2c verbunden. Ich nenne nach einem fehlgeschlagenen Compile die re2c-Binary um und lege unter selben Namen ein Script an, welches die original-Binary mit strace zur Fehlersuche aufruft:

#!/bin/bash
strace ./re2c.org $*

Ergebnis:

open("/tmp/tmpfuxtE34", O_RDWR|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV +++
./re2c: line 2:  6931 Segmentation fault      strace ./re2c.org $*

Also hat es mit /tmp zu tun? Die Datei existiert nicht, schreibrechte sollte der Prozess auch haben. /tmp ist auf dem System nicht speziell eingerichtet, es liegt auf der root mit ext4 und rw,relatime,data=ordered. Auf anderen Systemen, welche keine Probleme haben, liegt es im RAM. Ist eventuell ext4 und dessen Funktionsumfang das Problem? Also schnell ein mount -t tmpfs -o noexec,nosuid tmp /tmp hinterher und nochmal versucht – fehlerfrei. Vermutlich fehlt in ext4 eine Dateioperation oder irgendwo kracht es beim asynchronen Betrieb zwischen löschen und neu erstellen. Warum es ohne portage/ebuild funktioniert ist dann immer noch die Frage. Wie auch immer: tmpfs stand ohnehin noch auf der Todo-Liste, worksforme.