1 |
Hallo, |
2 |
|
3 |
der Compile-Vorgang bricht zb wiefolgt ab: |
4 |
/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 |
5 |
|
6 |
RAM und Swap sollten mit jeweils 16GB ausreichend groß dimensioniert |
7 |
sein. |
8 |
|
9 |
Nachdem ich das ganze gerade nochmal nachgeschaut habe kam mir aber eine |
10 |
andere Idee. Mein /tmp ist noch als ramfs eingebunden. Stammt noch aus |
11 |
einer Zeit, als ich mein rootfs als ramfs betrieben habe und an der Ecke |
12 |
rumgespielt habe. |
13 |
|
14 |
Nachdem ich das ganze umgeboben habe, klappt nun auch wieder das |
15 |
compilieren. Sieht so aus, als wurde hier das Limit on /tmp gerissen. |
16 |
Interessanterweise kam zu keinem Zeitpunkt eine Ausgabe im dmesg Log. |
17 |
Und der Rechner lief auch stabil weiter. |
18 |
|
19 |
Werde es mal noch weiter beobachten. |
20 |
|
21 |
Vielen Dank |
22 |
Martin |
23 |
|
24 |
On Thu, Mar 08, 2018 at 10:00:39AM +0100, Sven Eden wrote: |
25 |
> Hallo allerseits! |
26 |
> |
27 |
> > Gesendet: Mittwoch, 07. März 2018 um 23:29 Uhr |
28 |
> > Von: assabajanischer_hinterwaeldler@×××××.de |
29 |
> > |
30 |
> > seit einiger Zeit habe ich immer wieder Internal compiler errors mit der |
31 |
> > Meldung Segfault. Das ganze tritt vor allem bei größeren Programmen auf. |
32 |
> > Nach einiger Suche im Netz bin ich über RAM-Problem gestolpert. |
33 |
> > Allerdings sieht das memtester Ergebnis unauffällig aus. |
34 |
> |
35 |
> Wie äußert sich das denn? Greift der OOM Killer ein? |
36 |
> |
37 |
> > Aktuell verwende ich gcc-7.3 |
38 |
> > Daher habe ich schon vermutet, ob es ggf an der glibc Version liegt. |
39 |
> > Zumindest muss man hier etwas genauer aufpassen, wenn die Idee, wie man |
40 |
> > einen Compiler baut richtig verstanden habe, da hier nicht immer all |
41 |
> > Versionen kompatibel sind. |
42 |
> > Verwenden tue ich glibc-2.26-r6 |
43 |
> |
44 |
> Ein Upgrade auf gcc-7.3 von gcc-5.x, gcc-6.x oder gcc-7.x sollte |
45 |
> problemlos möglich sein. |
46 |
> Nach dem Switch auf gcc-7.3 mittels gcc-config (plus dem obligatorischen |
47 |
> ". /etc/profile") muss allerdings libtool neu gebaut werden. |
48 |
> |
49 |
> > Sofern ich es richtig beobachtet habe, trifft es immer wieder die |
50 |
> > gleichen Stellen bei den Programmen. |
51 |
> > |
52 |
> > Probiert habe ich auch schon die Anzahl der Threads und die erlaubte |
53 |
> > Load zu reduzieren, allerdings auch ohne Erfolg. |
54 |
> > |
55 |
> > Im Bugzilla auf gentoo.org habe ich aktuell keine Einträge gefunden, die |
56 |
> > in diese Richtung deuten. |
57 |
> > |
58 |
> > Betroffene Programme (nicht immer): |
59 |
> > - libreoffice |
60 |
> > - thunderbird |
61 |
> > - firefox |
62 |
> > Idr sind diese auch vollständig auf stable gesetzt. |
63 |
> |
64 |
> Diese Programme brauchen beim Linken sehr viel Speicher. Falls du also |
65 |
> kein Swap hast, kann das die Ursache sein. LTO erhöht den Speicherbedarf |
66 |
> ebenfalls, irgendwo zwischen "sehr" und "erheblich!". Und wenn du in |
67 |
> deinen C[XX]FLAGS ein "-g" drin hast, steigt der Speicherbedarf, vor Allem |
68 |
> beim Linken, exorbitant! |
69 |
> |
70 |
> Also: |
71 |
> - Ausreichend Speicher vorhanden (plus Swap) ? |
72 |
> - LTO aktiviert ? |
73 |
> - Debug Flags aktiviert ? |
74 |
> |
75 |
> Bei den drei Punkten würde ich zu suchen anfangen. |
76 |
> |
77 |
> Gruß |
78 |
> |
79 |
> Sven |
80 |
> |
81 |
> P.S Oder du versuchst mal qtwebkit oder gtk-webkit zu bauen, deren |
82 |
> Speicherbedarf beim Linken ist ebenfalls gewaltig! Mal sehen, ob die |
83 |
> funktionieren. |
84 |
> |