Hallo zusammen,

seit einiger Zeit habe ich immer wieder Internal compiler errors mit der Meldung Segfault. Das ganze tritt vor allem bei größeren Programmen auf.
Nach einiger Suche im Netz bin ich über RAM-Problem gestolpert.
Allerdings sieht das memtester Ergebnis unauffällig aus.

Aktuell verwende ich gcc-7.3
Daher habe ich schon vermutet, ob es ggf an der glibc Version liegt.
Zumindest muss man hier etwas genauer aufpassen, wenn die Idee, wie man
einen Compiler baut richtig verstanden habe, da hier nicht immer all
Versionen kompatibel sind.
Verwenden tue ich glibc-2.26-r6

Sofern ich es richtig beobachtet habe, trifft es immer wieder die
gleichen Stellen bei den Programmen.

Probiert habe ich auch schon die Anzahl der Threads und die erlaubte
Load zu reduzieren, allerdings auch ohne Erfolg.

Im Bugzilla auf gentoo.org habe ich aktuell keine Einträge gefunden, die
in diese Richtung deuten.

Betroffene Programme (nicht immer):
- libreoffice
- thunderbird
- firefox
Idr sind diese auch vollständig auf stable gesetzt.

Hat jemand von euch eine Idee?

Gruß
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo allerseits!

Gesendet: Mittwoch, 07. März 2018 um 23:29 Uhr Von: assabajanischer_hinterwaeldler@xunit.de

seit einiger Zeit habe ich immer wieder Internal compiler errors mit der Meldung Segfault. Das ganze tritt vor allem bei größeren Programmen auf. Nach einiger Suche im Netz bin ich über RAM-Problem gestolpert.
Allerdings sieht das memtester Ergebnis unauffällig aus.

Wie äußert sich das denn? Greift der OOM Killer ein?

Aktuell verwende ich gcc-7.3
Daher habe ich schon vermutet, ob es ggf an der glibc Version liegt. Zumindest muss man hier etwas genauer aufpassen, wenn die Idee, wie man
einen Compiler baut richtig verstanden habe, da hier nicht immer all Versionen kompatibel sind.
Verwenden tue ich glibc-2.26-r6

Ein Upgrade auf gcc-7.3 von gcc-5.x, gcc-6.x oder gcc-7.x sollte
problemlos möglich sein.
Nach dem Switch auf gcc-7.3 mittels gcc-config (plus dem obligatorischen
". /etc/profile") muss allerdings libtool neu gebaut werden.

Sofern ich es richtig beobachtet habe, trifft es immer wieder die
gleichen Stellen bei den Programmen.

Probiert habe ich auch schon die Anzahl der Threads und die erlaubte
Load zu reduzieren, allerdings auch ohne Erfolg.

Im Bugzilla auf gentoo.org habe ich aktuell keine Einträge gefunden, die
in diese Richtung deuten.

Betroffene Programme (nicht immer):
- libreoffice
- thunderbird
- firefox
Idr sind diese auch vollständig auf stable gesetzt.

Diese Programme brauchen beim Linken sehr viel Speicher. Falls du also
kein Swap hast, kann das die Ursache sein. LTO erhöht den Speicherbedarf ebenfalls, irgendwo zwischen "sehr" und "erheblich!". Und wenn du in
deinen C[XX]FLAGS ein "-g" drin hast, steigt der Speicherbedarf, vor Allem
beim Linken, exorbitant!

Also:
- Ausreichend Speicher vorhanden (plus Swap) ?
- LTO aktiviert ?
- Debug Flags aktiviert ?

Bei den drei Punkten würde ich zu suchen anfangen.

Gruß

Sven

P.S Oder du versuchst mal qtwebkit oder gtk-webkit zu bauen, deren
Speicherbedarf beim Linken ist ebenfalls gewaltig! Mal sehen, ob die
funktionieren.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo,

der Compile-Vorgang bricht zb wiefolgt ab: /var/tmp/portage/app-office/libreoffice-5.4.5.1/work/libreoffice-5.4.5.1/include/rtl/ustring.hxx:2632:31:internal compiler error: Segmentation fault

RAM und Swap sollten mit jeweils 16GB ausreichend groß dimensioniert
sein.

Nachdem ich das ganze gerade nochmal nachgeschaut habe kam mir aber eine
andere Idee. Mein /tmp ist noch als ramfs eingebunden. Stammt noch aus
einer Zeit, als ich mein rootfs als ramfs betrieben habe und an der Ecke rumgespielt habe.

Nachdem ich das ganze umgeboben habe, klappt nun auch wieder das
compilieren. Sieht so aus, als wurde hier das Limit on /tmp gerissen. Interessanterweise kam zu keinem Zeitpunkt eine Ausgabe im dmesg Log.
Und der Rechner lief auch stabil weiter.

Werde es mal noch weiter beobachten.

Vielen Dank
Martin

On Thu, Mar 08, 2018 at 10:00:39AM +0100, Sven Eden wrote:

Hallo allerseits!

Gesendet: Mittwoch, 07. März 2018 um 23:29 Uhr Von: assabajanischer_hinterwaeldler@xunit.de

seit einiger Zeit habe ich immer wieder Internal compiler errors mit der Meldung Segfault. Das ganze tritt vor allem bei größeren Programmen auf. Nach einiger Suche im Netz bin ich über RAM-Problem gestolpert.
Allerdings sieht das memtester Ergebnis unauffällig aus.

Wie äußert sich das denn? Greift der OOM Killer ein?

Aktuell verwende ich gcc-7.3
Daher habe ich schon vermutet, ob es ggf an der glibc Version liegt. Zumindest muss man hier etwas genauer aufpassen, wenn die Idee, wie man einen Compiler baut richtig verstanden habe, da hier nicht immer all Versionen kompatibel sind.
Verwenden tue ich glibc-2.26-r6

Ein Upgrade auf gcc-7.3 von gcc-5.x, gcc-6.x oder gcc-7.x sollte
problemlos möglich sein.
Nach dem Switch auf gcc-7.3 mittels gcc-config (plus dem obligatorischen
". /etc/profile") muss allerdings libtool neu gebaut werden.

Sofern ich es richtig beobachtet habe, trifft es immer wieder die
gleichen Stellen bei den Programmen.

Probiert habe ich auch schon die Anzahl der Threads und die erlaubte
Load zu reduzieren, allerdings auch ohne Erfolg.

Im Bugzilla auf gentoo.org habe ich aktuell keine Einträge gefunden, die
in diese Richtung deuten.

Betroffene Programme (nicht immer):
- libreoffice
- thunderbird
- firefox
Idr sind diese auch vollständig auf stable gesetzt.

Diese Programme brauchen beim Linken sehr viel Speicher. Falls du also
kein Swap hast, kann das die Ursache sein. LTO erhöht den Speicherbedarf ebenfalls, irgendwo zwischen "sehr" und "erheblich!". Und wenn du in
deinen C[XX]FLAGS ein "-g" drin hast, steigt der Speicherbedarf, vor Allem beim Linken, exorbitant!

Also:
- Ausreichend Speicher vorhanden (plus Swap) ?
- LTO aktiviert ?
- Debug Flags aktiviert ?

Bei den drei Punkten würde ich zu suchen anfangen.

Gruß

Sven

P.S Oder du versuchst mal qtwebkit oder gtk-webkit zu bauen, deren
Speicherbedarf beim Linken ist ebenfalls gewaltig! Mal sehen, ob die
funktionieren.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Fri, 09 Mar 2018 00:16:18 +0100 schrieb assabajanischer_hinterwaeldler:

Hallo,

der Compile-Vorgang bricht zb wiefolgt ab: /var/tmp/portage/app-office/libreoffice-5.4.5.1/work/libreoffice-5.4.5.1/include/rtl/ustring.hxx:2632:31:internal compiler error: Segmentation fault

RAM und Swap sollten mit jeweils 16GB ausreichend groß dimensioniert
sein.

Solltest du die Pakete in tmpfs bauen, ist das nicht gerade viel.

Nachdem ich das ganze gerade nochmal nachgeschaut habe kam mir aber eine andere Idee. Mein /tmp ist noch als ramfs eingebunden. Stammt noch aus
einer Zeit, als ich mein rootfs als ramfs betrieben habe und an der Ecke rumgespielt habe.

/tmp als tmpfs zu haben, ist ein Standard-Verhalten, wenn du mit systemd bootest. /var/tmp dagegen sollte dann aber kein tmpfs sein, und hier baut Portage per default.

Nachdem ich das ganze umgeboben habe, klappt nun auch wieder das
compilieren. Sieht so aus, als wurde hier das Limit on /tmp gerissen. Interessanterweise kam zu keinem Zeitpunkt eine Ausgabe im dmesg Log.
Und der Rechner lief auch stabil weiter.

Werde es mal noch weiter beobachten.

Ich verwende hier /var/tmp/portage als tmpfs mit Automount. Dadurch
werden die Inhalte weggeworfen, sobald Portage fertig ist. Das Limit
steht auf 150%, ich habe 16G RAM und 60G Swap.

Die großen Pakete biege ich per package.env aber auf ein anderes
Verzeichnis um und baue sie explizit ohne "-g":

$ cat /etc/portage/env/no-tmpfs
PORTAGE_TMPDIR="/usr/src"

$ cat /etc/portage/env/no-debug
CFLAGS="-O3 -march=native -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
CPPFLAGS="${CFLAGS}"

$ cat /etc/portage/package.env
app-office/libreoffice no-debug no-tmpfs
[...und weitere...]


--
Regards,
Kai

Replies to list-only preferred.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)