# Hangup beim bauen von dev-libs/boost

## schmidicom

Beim heutigen Versuch das aktuelle dev-libs/boost-1.55.0-r2 zu bauen hat sich mein Laptop komplett aufgehängt, ein abwürgen (Einschaltknopf 5s lang drücken) war die letzte Option. Aber zum Glück zeichnete journald doch noch etwas auf und konnte es sogar auf der Festplatte speichern wodurch das Log noch zur Verfügung steht.

Nun verstehe ich jedoch nicht so ganz wie es dazu kommen konnte, aber vielleicht kann ja einer von euch etwas Licht in die Sache bringen?

```
Nov 20 14:40:23 slap kernel: cc1plus invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Nov 20 14:40:23 slap kernel: cc1plus cpuset=/ mems_allowed=0

Nov 20 14:40:23 slap kernel: CPU: 3 PID: 4320 Comm: cc1plus Tainted: P           O   3.17.3 #1

Nov 20 14:40:23 slap kernel: Hardware name: LENOVO 20B2000KMZ/20B2000KMZ, BIOS HRET24WW (1.12) 01/24/2014

Nov 20 14:40:23 slap kernel:  0000000000000000 ffffffff815e62ec ffff88007479a9e0 ffffffff815e0e8e

Nov 20 14:40:23 slap kernel:  ffff88009a18fa68 0000000000000003 ffff8800a1889b38 0000000000000000

Nov 20 14:40:23 slap kernel:  0000000000000020 ffffffff8109d16e 00000000000201da ffff880015d2c538

Nov 20 14:40:23 slap kernel: Call Trace:

Nov 20 14:40:23 slap kernel:  [<ffffffff815e62ec>] ? dump_stack+0x41/0x51

Nov 20 14:40:23 slap kernel:  [<ffffffff815e0e8e>] ? dump_header+0x70/0x1e1

Nov 20 14:40:23 slap kernel:  [<ffffffff8109d16e>] ? ktime_get+0x3e/0xa0

Nov 20 14:40:23 slap kernel:  [<ffffffff810e3309>] ? oom_kill_process+0x269/0x3b0

Nov 20 14:40:23 slap kernel:  [<ffffffff810e2e20>] ? find_lock_task_mm+0x40/0xa0

Nov 20 14:40:23 slap kernel:  [<ffffffff810e3a62>] ? out_of_memory+0x492/0x4d0

Nov 20 14:40:23 slap kernel:  [<ffffffff815e1a70>] ? __alloc_pages_slowpath+0x6e8/0x84b

Nov 20 14:40:23 slap kernel:  [<ffffffff810e92b3>] ? __alloc_pages_nodemask+0x203/0x270

Nov 20 14:40:23 slap kernel:  [<ffffffff81121e80>] ? alloc_pages_current+0xb0/0x180

Nov 20 14:40:23 slap kernel:  [<ffffffff810e2210>] ? filemap_fault+0x1b0/0x430

Nov 20 14:40:23 slap kernel:  [<ffffffff81103525>] ? __do_fault+0x35/0x90

Nov 20 14:40:23 slap kernel:  [<ffffffff8110541d>] ? do_read_fault.isra.70+0x5d/0x2f0

Nov 20 14:40:23 slap kernel:  [<ffffffff81106c36>] ? handle_mm_fault+0x746/0xfd0

Nov 20 14:40:23 slap kernel:  [<ffffffff81039a67>] ? __do_page_fault+0x187/0x490

Nov 20 14:40:23 slap kernel:  [<ffffffff8107359b>] ? put_prev_entity+0x7b/0x3c0

Nov 20 14:40:23 slap kernel:  [<ffffffff8106f026>] ? set_next_entity+0x66/0x80

Nov 20 14:40:23 slap kernel:  [<ffffffff810766dd>] ? pick_next_task_fair+0x61d/0x820

Nov 20 14:40:23 slap kernel:  [<ffffffff815eced2>] ? page_fault+0x22/0x30

Nov 20 14:40:23 slap kernel: Mem-Info:

Nov 20 14:40:23 slap kernel: Node 0 DMA per-cpu:

Nov 20 14:40:23 slap kernel: CPU    0: hi:    0, btch:   1 usd:   0

Nov 20 14:40:23 slap kernel: CPU    1: hi:    0, btch:   1 usd:   0

Nov 20 14:40:23 slap kernel: CPU    2: hi:    0, btch:   1 usd:   0

Nov 20 14:40:23 slap kernel: CPU    3: hi:    0, btch:   1 usd:   0

Nov 20 14:40:23 slap kernel: Node 0 DMA32 per-cpu:

Nov 20 14:40:23 slap kernel: CPU    0: hi:  186, btch:  31 usd:  44

Nov 20 14:40:23 slap kernel: CPU    1: hi:  186, btch:  31 usd: 160

Nov 20 14:40:23 slap kernel: CPU    2: hi:  186, btch:  31 usd: 178

Nov 20 14:40:23 slap kernel: CPU    3: hi:  186, btch:  31 usd:  66

Nov 20 14:40:23 slap kernel: Node 0 Normal per-cpu:

Nov 20 14:40:23 slap kernel: CPU    0: hi:   42, btch:   7 usd:  22

Nov 20 14:40:23 slap kernel: CPU    1: hi:   42, btch:   7 usd:   6

Nov 20 14:40:23 slap kernel: CPU    2: hi:   42, btch:   7 usd:   6

Nov 20 14:40:23 slap kernel: CPU    3: hi:   42, btch:   7 usd:   4

Nov 20 14:40:23 slap kernel: active_anon:726506 inactive_anon:2456 isolated_anon:0

                              active_file:2771 inactive_file:3026 isolated_file:32

                              unevictable:16 dirty:0 writeback:0 unstable:0

                              free:20272 slab_reclaimable:5569 slab_unreclaimable:6641

                              mapped:2742 shmem:2654 pagetables:9224 bounce:0

                              free_cma:1959

Nov 20 14:40:23 slap kernel: Node 0 DMA free:12648kB min:336kB low:420kB high:504kB active_anon:2648kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB is

Nov 20 14:40:23 slap kernel: lowmem_reserve[]: 0 2638 3081 3081

Nov 20 14:40:23 slap kernel: Node 0 DMA32 free:59152kB min:57580kB low:71972kB high:86368kB active_anon:2500712kB inactive_anon:8156kB active_file:10544kB inactive_file:10884kB unevictable:64k

Nov 20 14:40:23 slap kernel: lowmem_reserve[]: 0 0 442 442

Nov 20 14:40:23 slap kernel: Node 0 Normal free:9288kB min:9660kB low:12072kB high:14488kB active_anon:402664kB inactive_anon:1668kB active_file:540kB inactive_file:1232kB unevictable:0kB isol

Nov 20 14:40:23 slap kernel: lowmem_reserve[]: 0 0 0 0

Nov 20 14:40:23 slap kernel: Node 0 DMA: 3*4kB (UE) 11*8kB (UE) 14*16kB (UEM) 5*32kB (UE) 2*64kB (EM) 0*128kB 3*256kB (UEM) 2*512kB (UE) 2*1024kB (EM) 2*2048kB (ER) 1*4096kB (M) = 12644kB

Nov 20 14:40:23 slap kernel: Node 0 DMA32: 993*4kB (UE) 1122*8kB (UEM) 774*16kB (UEM) 315*32kB (UE) 158*64kB (UE) 76*128kB (UEM) 15*256kB (UEM) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 59092kB

Nov 20 14:40:23 slap kernel: Node 0 Normal: 1754*4kB (UEC) 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB (R) 0*4096kB = 9064kB

Nov 20 14:40:23 slap kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB

Nov 20 14:40:23 slap kernel: 8667 total pagecache pages

Nov 20 14:40:23 slap kernel: 0 pages in swap cache

Nov 20 14:40:23 slap kernel: Swap cache stats: add 0, delete 0, find 0/0

Nov 20 14:40:23 slap kernel: Free swap  = 0kB

Nov 20 14:40:23 slap kernel: Total swap = 0kB

Nov 20 14:40:23 slap kernel: 825523 pages RAM

Nov 20 14:40:23 slap kernel: 0 pages HighMem/MovableOnly

Nov 20 14:40:23 slap kernel: 13606 pages reserved

Nov 20 14:40:23 slap kernel: 0 pages hwpoisoned

Nov 20 14:40:23 slap kernel: [ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

Nov 20 14:40:23 slap kernel: [  103]     0   103     9883       62      23        0             0 systemd-journal

Nov 20 14:40:23 slap kernel: [  129]     0   129    10051      284      20        0         -1000 systemd-udevd

Nov 20 14:40:23 slap kernel: [  134]   104   134     6546       48      16        0             0 systemd-timesyn

Nov 20 14:40:23 slap kernel: [  205]     0   205    90285     1456      61        0             0 NetworkManager

Nov 20 14:40:23 slap kernel: [  208]     0   208    79452      276      59        0             0 ModemManager

Nov 20 14:40:23 slap kernel: [  211]     0   211     5388       84      15        0             0 systemd-logind

Nov 20 14:40:23 slap kernel: [  213]   105   213     6199      243      18        0          -900 dbus-daemon

Nov 20 14:40:23 slap kernel: [  225]   106   225   127571     2054      46        0             0 polkitd

Nov 20 14:40:23 slap kernel: [  229]     0   229     4483       40      13        0             0 agetty

Nov 20 14:40:23 slap kernel: [  230]     0   230    67247      285      35        0             0 lightdm

Nov 20 14:40:23 slap kernel: [  237]     0   237    61832    10856     130        0             0 X

Nov 20 14:40:23 slap kernel: [  250]     0   250    12524      159      28        0         -1000 sshd

Nov 20 14:40:23 slap kernel: [  252]     0   252    10743      174      24        0             0 wpa_supplicant

Nov 20 14:40:23 slap kernel: [  279]     0   279    69768      831      41        0             0 accounts-daemon

Nov 20 14:40:23 slap kernel: [  286]     0   286     6691      121      17        0             0 systemd

Nov 20 14:40:23 slap kernel: [  287]     0   287    12814      379      25        0             0 (sd-pam)

Nov 20 14:40:23 slap kernel: [  290]     0   290     4033     1618      12        0             0 dhclient

Nov 20 14:40:23 slap kernel: [  296]     0   296     6093       67      16        0             0 dbus-launch

Nov 20 14:40:23 slap kernel: [  297]     0   297     5975       61      16        0             0 dbus-daemon

Nov 20 14:40:23 slap kernel: [  300]     0   300    70043      361      56        0             0 upowerd

Nov 20 14:40:23 slap kernel: [  333]     0   333    41349      255      51        0             0 lightdm

Nov 20 14:40:23 slap kernel: [  339] 10000   339     8795      134      22        0             0 systemd

Nov 20 14:40:23 slap kernel: [  340] 10000   340    12814      382      25        0             0 (sd-pam)

Nov 20 14:40:23 slap kernel: [  342] 10000   342     1056       31       9        0             0 startkde

Nov 20 14:40:23 slap kernel: [  352] 10000   352     6093       66      17        0             0 dbus-launch

Nov 20 14:40:23 slap kernel: [  353] 10000   353     6169      246      17        0             0 dbus-daemon

Nov 20 14:40:23 slap kernel: [  375] 10000   375     4681       53      13        0             0 gpg-agent

Nov 20 14:40:23 slap kernel: [  388] 10000   388    92302     1568     155        0             0 kdeinit4

Nov 20 14:40:23 slap kernel: [  389] 10000   389    93301     1551     147        0             0 klauncher

Nov 20 14:40:23 slap kernel: [  391] 10000   391   317924     3567     284        0             0 kded4

Nov 20 14:40:23 slap kernel: [  393] 10000   393     4512       63      16        0             0 gam_server

Nov 20 14:40:23 slap kernel: [  396] 10000   396   115084     2270     188        0             0 kglobalaccel

Nov 20 14:40:23 slap kernel: [  405] 10000   405   174881     1764     153        0             0 kactivitymanage

Nov 20 14:40:23 slap kernel: [  409]     0   409    91019      790      45        0             0 udisksd

Nov 20 14:40:23 slap kernel: [  416] 10000   416     1030       17       8        0             0 kwrapper4

Nov 20 14:40:23 slap kernel: [  417] 10000   417   138169     2186     197        0             0 ksmserver

Nov 20 14:40:23 slap kernel: [  427] 10000   427   749980     5013     263        0             0 kwin

Nov 20 14:40:23 slap kernel: [  436] 10000   436    86560     1277     151        0             0 baloo_file

Nov 20 14:40:23 slap kernel: [  437] 10000   437   808029    16309     328        0             0 plasma-desktop

Nov 20 14:40:23 slap kernel: [  445] 10000   445    77722     1139     140        0             0 kuiserver

Nov 20 14:40:23 slap kernel: [  448] 10000   448     2404       83      10        0             0 ksysguardd

Nov 20 14:40:23 slap kernel: [  450] 10000   450    75508      435      43        0             0 akonadi_control

Nov 20 14:40:23 slap kernel: [  452] 10000   452   547085     2885     171        0             0 akonadiserver

Nov 20 14:40:23 slap kernel: [  455] 10000   455   569791    12021     101        0             0 mysqld

Nov 20 14:40:23 slap kernel: [  486] 10000   486   376032     4079     285        0             0 krunner

Nov 20 14:40:23 slap kernel: [  488] 10000   488   176220     3253     201        0             0 kmix

Nov 20 14:40:23 slap kernel: [  500] 10000   500   130870      612      96        0             0 pulseaudio

Nov 20 14:40:23 slap kernel: [  526] 10000   526    88791     1114     129        0             0 akonadi_agent_l

Nov 20 14:40:23 slap kernel: [  527] 10000   527   140601     2234     246        0             0 akonadi_archive

Nov 20 14:40:23 slap kernel: [  528] 10000   528    91305     1597     167        0             0 akonadi_baloo_i

Nov 20 14:40:23 slap kernel: [  529] 10000   529    86637     1098     123        0             0 akonadi_agent_l

Nov 20 14:40:23 slap kernel: [  530] 10000   530    86450     1254     159        0             0 akonadi_followu

Nov 20 14:40:23 slap kernel: [  531] 10000   531    87302     1118     124        0             0 akonadi_agent_l

Nov 20 14:40:23 slap kernel: [  532] 10000   532   153942     1993     183        0             0 akonadi_imap_re

Nov 20 14:40:23 slap kernel: [  533] 10000   533    88794     1115     125        0             0 akonadi_agent_l

Nov 20 14:40:23 slap kernel: [  534] 10000   534    92167     1306     168        0             0 akonadi_maildis

Nov 20 14:40:23 slap kernel: [  535] 10000   535   140630     2186     253        0             0 akonadi_mailfil

Nov 20 14:40:23 slap kernel: [  536] 10000   536    84054     1227     151        0             0 akonadi_migrati

Nov 20 14:40:23 slap kernel: [  537] 10000   537   100728     1429     181        0             0 akonadi_newmail

Nov 20 14:40:23 slap kernel: [  538] 10000   538   135853     2090     242        0             0 akonadi_sendlat

Nov 20 14:40:23 slap kernel: [  579] 10000   579     2382       19      12        0             0 cat

Nov 20 14:40:23 slap kernel: [  580] 10000   580     2382       19      10        0             0 cat

Nov 20 14:40:23 slap kernel: [  581] 10000   581     2382       19      10        0             0 cat

Nov 20 14:40:23 slap kernel: [  582] 10000   582     2382       18      10        0             0 cat

Nov 20 14:40:23 slap kernel: [  583] 10000   583     2382       19      11        0             0 cat

Nov 20 14:40:23 slap kernel: [  585] 10000   585   118678     2100     192        0             0 kwalletd

Nov 20 14:40:23 slap kernel: [  593] 10000   593   136402     5629     247        0             0 python2.7

Nov 20 14:40:23 slap kernel: [  606] 10000   606   102447     1201     155        0             0 polkit-kde-auth

Nov 20 14:40:23 slap kernel: [  608] 10000   608    47435     2700      91        0             0 python2.7

Nov 20 14:40:23 slap kernel: [  609] 10000   609   107229     1526     195        0             0 korgac

Nov 20 14:40:23 slap kernel: [  610] 10000   610    40694     2419      78        0             0 python2.7

Nov 20 14:40:23 slap kernel: [  614] 10000   614   117039     2129     192        0             0 klipper

Nov 20 14:40:23 slap kernel: [  635]     0   635   112704     2994     170        0             0 konsole

Nov 20 14:40:23 slap kernel: [  639]     0   639     6404       99      18        0             0 bash

Nov 20 14:40:23 slap kernel: [  645] 10000   645   104286     1466     154        0             0 knotify4

Nov 20 14:40:23 slap kernel: [  647]     0   647    19899      191      40        0             0 cupsd

Nov 20 14:40:23 slap kernel: [  662]     0   662   134353   104018     269        0             0 emerge

Nov 20 14:40:23 slap kernel: [ 3526]   250  3526     1038       36       9        0             0 sandbox

Nov 20 14:40:23 slap kernel: [ 3528]   250  3528     7543      676      20        0             0 ebuild.sh

Nov 20 14:40:23 slap kernel: [ 3545]   250  3545     7783      921      20        0             0 ebuild.sh

Nov 20 14:40:23 slap kernel: [ 3562]   250  3562     3540       82      13        0             0 tee

Nov 20 14:40:23 slap kernel: [ 3617]   250  3617     3540       81      13        0             0 tee

Nov 20 14:40:23 slap kernel: [ 3668]   250  3668    19244    11109      42        0             0 b2

Nov 20 14:40:23 slap kernel: [ 4318]   250  4318     2113       28       9        0             0 sh

Nov 20 14:40:23 slap kernel: [ 4319]   250  4319     4494      106      14        0             0 x86_64-pc-linux

Nov 20 14:40:23 slap kernel: [ 4320]   250  4320   272965   261359     536        0             0 cc1plus

Nov 20 14:40:23 slap kernel: [ 4321]   250  4321     7577     2074      20        0             0 as

Nov 20 14:40:23 slap kernel: [ 4334]   250  4334     2113       28      11        0             0 sh

Nov 20 14:40:23 slap kernel: [ 4335]   250  4335     4494      104      15        0             0 x86_64-pc-linux

Nov 20 14:40:23 slap kernel: [ 4336]   250  4336   121338   106930     235        0             0 cc1plus

Nov 20 14:40:23 slap kernel: [ 4337]   250  4337     6818     1311      18        0             0 as

Nov 20 14:40:23 slap kernel: [ 4338]   250  4338     2113       28      11        0             0 sh

Nov 20 14:40:23 slap kernel: [ 4339]   250  4339     4494      105      14        0             0 x86_64-pc-linux

Nov 20 14:40:23 slap kernel: [ 4340]   250  4340   143348   131154     279        0             0 cc1plus

Nov 20 14:40:23 slap kernel: [ 4341]   250  4341     6818     1312      16        0             0 as

Nov 20 14:40:23 slap kernel: Out of memory: Kill process 4320 (cc1plus) score 330 or sacrifice child

Nov 20 14:40:23 slap kernel: Killed process 4320 (cc1plus) total-vm:1091860kB, anon-rss:1045436kB, file-rss:0kB
```

----------

## mrsteven

Bin da auch etwas ratlos: Ich sehe anhand deines Logs, dass dem Kernel der RAM ausgegangen ist und er deswegen den C++-Compiler abgeschossen hat (OOM-Kill). Komplett aufhängen sollte sich der Rechner aber deswegen nicht. Konntest du die Maus noch bewegen? Welche Kernelversion ist das?

So wie es aussieht kompilierst du mehrere Module parallel (MAKEOPTS=-j4 o.ä.). Du könntest mal versuchen das abzustellen (MAKEOPTS=-j1 oder weg damit). Das spart Speicher. Hängen bleiben sollte er aber auch dann nicht, wenn ihm der Speicher ausgeht…

----------

## schmidicom

Es ist der Kernel 3.17.3 und nein die Maus lies sich nicht mehr bewegen, er reagierte ja nicht einmal mehr auf den Einschaltknopf (mit Ausnahme vom hardoff mit 5s). Auch ein Zugriff übers Netzwerk via ssh war nicht mehr möglich also muss sich weit mehr als nur der Desktop aufgehängt haben. Und es ist auch nicht reproduzierbar, beim zweiten Versuch boost zu bauen lief alles trotz parallelem compilieren problemlos durch.

Ich verstehe einfach nicht wie sowas zum totalen Hangup führen kann...

----------

## Klaus Meier

Jetzt wo du eo sagst, ich hatte es auch schon ab und an mal. Es trat immer dann auf, wenn ich mehrere Pakete gleichzeitig kompiliert habe.

Es ging dann gar nichts mehr, nur noch ausschalten. Exakt die gleichen Symptome wie bei dir. Wie viel Speicher hast du denn und was für einen Wert bei -j? In der letzten Zeit ist es mir aber nicht mehr untergekommen. Zum einen bin ich gerade beim gcc 4.9.2 und beim Kernel 3.17.3. Am Kernel wird es dann wohl nicht liegen, den hast du ja auch.

----------

## schmidicom

Bis jetzt ist es nur auf dem Laptop vorgekommen und der hat 4GB RAM nen GCC 4.8.3 und die MAKEOPTS steht auf "-j3".

Aber wenn Systemressourcen das Problem wären müsste der Kernel doch einfach nur den Prozess killen und alles andere normal weiterlaufen oder?

----------

## Klaus Meier

Na klar sollte das so sein, außer es gibt irgendwo einen Bug. Hast wohl auch keinen großen Bock, es zu reproduzieren. Wenn ja, starte mal emerge mehrfach. Sollten aber schon größere Sachen sein.

----------

## schmidicom

 *Klaus Meier wrote:*   

> Hast wohl auch keinen großen Bock, es zu reproduzieren.

 

Nicht wenn ich dadurch irgendwann mein Dateisystem schrotte.

----------

## Klaus Meier

Mit dem gcc 4.9 ist das Problem bei mir nicht mehr aufgetaucht, muss aber nichts heißen, wenn man es nur ab und an mal hat.

----------

## mrsteven

Es gibt wohl ein paar OOM-bezogene Bugs:

https://bugzilla.kernel.org/buglist.cgi?quicksearch=OOM

Vielleicht werdet ihr ja da fündig. Ich meine mich zu erinnern, dass es mit cgroups auch Freezes geben kann, wenn der Speicher voll läuft.

Eine Idee wäre es, eine minimale VM mit relativ wenig RAM aufzusetzen und zu schauen, ob man es da reproduzieren kann…

----------

## schmidicom

Es gibt neue Infos:

Inzwischen kann ich mit Sicherheit sagen das es bei meinem Laptop jedes mal passiert wenn neben dem kompilieren von boost auch der KDE am laufen ist. Sobald der GCC versucht etwas grösseres zu kompilieren Hangt sich der KDE (und/oder eventuell auch der X11) komplett auf und der Laptop reagiert auf keine Eingabegeräte mehr. Auch der Zugriff über das Netzwerk (SSH) ist zu diesem Zeitpunkt nicht mehr möglich.

Beim letzten Hangup bewegte sich allerdings die Maus noch ein bisschen (ganz langsam aber nicht mehr kontrollierbar), fasst so als ob der X11 noch dabei wäre die letzte Eingabe zu verarbeiten.

----------

## Klaus Meier

Also zum einen kannst du den Wert von -j reduzieren. Aber so eine Idee von mir, versuche es mal mit dem gcc 4.9. Seit dem ich den nutze, ist dieses Problem bei mir nicht mehr aufgetaucht. Wenn das bei dir auch so ist, dann könnte es ein Problem mit der Speicherverwaltung vom gcc 4.8 sein.

----------

## schmidicom

Ist vielleicht doch noch ein bisschen früh für ein Update oder? Der GCC 4.9 hat noch nicht einmal ein keyword:

```
$ emerge -pv gcc:4.9

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild  NS   *] sys-devel/gcc-4.9.2:4.9 [4.8.3:4.8] USE="cxx fortran gcj go graphite (multilib) nls nptl objc objc++ objc-gc openmp sanitize (-altivec) -awt -doc (-fixed-point) (-hardened) (-libssp) (-multislot) -nopie -nossp -regression-test -vanilla" 87,866 kB

Total: 1 package (1 in new slot), Size of downloads: 87,866 kB

The following keyword changes are necessary to proceed:

 (see "package.accept_keywords" in the portage(5) man page for more details)

# required by gcc:4.9 (argument)

=sys-devel/gcc-4.9.2 **

NOTE: The --autounmask-keep-masks option will prevent emerge

      from creating package.unmask or ** keyword changes.
```

Und solange ich grössere Updates ohne laufenden KDE noch emergen kann ist es ja noch nicht ganz so schlimm, oder könnte es bei einem kaputten Speichermanagement im GCC noch weitere Probleme geben? Defekte builds, eventuell...?

----------

## Josef.95

Sorry, aber warum stellst du zu deinen 4 GB RAM nicht noch ein wenig SWAP mit bereit? (ich denke 2 GB sollten schon reichen).

boost ist vermutlich nicht das einzige Paket was zum bauen viel virtuellen Speicher benötigt - bei webkit-gtk und qtwebkit:5 wird es dir vermutlich ähnlich ergehen.

----------

## schmidicom

Ich dachte immer das "swap" auf einer SSD keine sonderlich gute Idee wäre, zumindest nicht wenn diese länger leben soll.

EDIT:

Außerdem, früher konnte ich auch im KDE eingeloggt sein und gleichzeitig ein grösseres Paket kompilieren ohne das sich die Kiste aufgehängt hat, schlimmstenfalls wurde der build einfach abgebrochen aber mehr ist nicht passiert. Erst seit kurzem hat dieses Verhalten angefangen, wobei es mir leider absolut nicht möglich ist zu sagen nach welchem Update das anfing da man ja auch nicht jeden Tag ein boost, libreoffice oder auch chromium installiert.Last edited by schmidicom on Tue Nov 25, 2014 1:24 pm; edited 1 time in total

----------

## Klaus Meier

Ich habe 4GB RAM und 8GB swap und hatte es auch ab und an mal. Hab mir da nur nie viel bei gedacht.

Edit:

Ja, jetzt wo du es sagst, es trat immer auf, wenn ich parallel zu webkit-gtk noch etwas anderes gestartet habe.

----------

## franzf

Schön dass das auch anderen so geht.

4GB RAM, 4GB SWAP, auf ner 256GB Laptop HDD. Mit gcc-4.8.3 musste ich bei zahlreichen Paketen die MAKEOPTS deutlich runterschrauben. Von -j4 auf -j2, teilweise sogar -j1.

Wo ich früher bei normaler Desktopnutzung (firefox, urxvt+tmux, vim, ...) problemlos alles mit -j4 durchbrachte, habe ich jetzt Probleme. Ich musste für einige Sachen sogar distcc deaktivieren, weil allein der Präprozessor für paar pupsige Files den Rechner in die Knie zwang.

Kandidaten sind z.B. llvm, ldc2, inkscape, webkit-gtk (das geht so gut wie gar nicht mehr...)

Ich warte jetzt noch ein paar Wochen, dann schau ich ob gcc-4.9 was hilft...

----------

## Josef.95

Hm, habt ihr PORTAGE_TMPDIR eventuell im tmpfs mounted?

Das wird bei solch großen Brocken wie boost, webkit usw mit so wenig virtuellen Speicher vermutlich knapp.

Ich hatte bis vor einigen Wochen auf meinem alten Rechner nur 2 GB RAM verfügbar (mehr ging nicht rein), dazu etwa 3GB SWAP,

damit ließen sich Pakete wie boost, und firefox noch einwandfrei bauen - mit gcc-4.8.3, MAKEOPTS=-j3, und PORTAGE_TMPDIR für diese Pakete nicht im tmpfs.

Beim bauen von qtwebkit:5 wurde es aber allmählich auch knapp, da ging viel viel Zeit fürs swappen drauf :-/

Nungut, ich hab mir nun (nach ~7 Jahren) auch mal ein frisches Board mit mehr RAM gegönnt :)

----------

## schmidicom

 *Josef.95 wrote:*   

> Hm, habt ihr PORTAGE_TMPDIR eventuell im tmpfs mounted?

 

Nö.

Sowas mache ich, SSD hin oder her, erst wenn definitiv genug RAM (8GB+) da ist.

----------

## SkaaliaN

Bei mir hat sich die Kiste ebenfalls aufgehangen.

Ich habe einfach die MAKEOPTS= in der make.conf für den emerge auf j1 eingesetzt.

Daraufhin lief es ohne Probleme durch. Dann wieder anpassen und alles ist gut.

----------

## schmidicom

Bei mir (auf dem Laptop) hilft leider auch kein "-j1", sobald gleichzeitig der KDE-Desktop am laufen ist kommt es mit 100% Wahrscheinlichkeit zum Hangup.

EDIT (13.02.2015):

Da der gcc 4.9 inzwischen zum testen freigegeben wurde habe ich mir den jetzt mal auf meinem Laptop installiert und selbst das mit zwei Hangups.

Hoffentlich bin ich damit dieses überaus lästige Speicherverwaltungsproblem endlich los...

----------

## schmidicom

Von wegen, besser geworden... So langsam habe ich echt eine Stinkwut auf den GCC.

Ich musste "net-libs/webkit-gtk" mit clang/LLVM bauen weil der GCC jedesmal reproduzierbar sogar meinen großen Rechner mit mehr als genug RAM gekillt hat. Dazu kommt noch das irgendein "conftest"-Teil (vermutlich für gcj) im GCC 4.9 ebenfalls reproduzierbar einen kompletten hangup fabriziert.

----------

## Klaus Meier

Habe ich letztens in Wiki gelesen, wenn du aus den CFlags -pipe raus nimmst, dann wird weniger Speicher genutzt..

Aber irgendwie ist bei dir etwas anderes faul. Ich habe auch 4GB und bekomme alles mit -pipe und -j3 übersetzt. Gut, ich habe auch noch 8GB Swap. Aber wenn es bei dir nicht mal mit -j1 geht, dann solltest du nicht auf den gcc schimpfen, dann ist bei dir irgend etwas nicht so, wie es sein sollte.

Conftest hatte ich auch mal, dass das geklemmt hat. Habe ich mit kill abgeschossen und dann ging es ohne Probleme weiter.

----------

## schmidicom

 *Klaus Meier wrote:*   

> Habe ich letztens in Wiki gelesen, wenn du aus den CFlags -pipe raus nimmst, dann wird weniger Speicher genutzt..
> 
> Aber irgendwie ist bei dir etwas anderes faul. Ich habe auch 4GB und bekomme alles mit -pipe und -j3 übersetzt. Gut, ich habe auch noch 8GB Swap. Aber wenn es bei dir nicht mal mit -j1 geht, dann solltest du nicht auf den gcc schimpfen, dann ist bei dir irgend etwas nicht so, wie es sein sollte.

 

Ich würde wirklich gern wissen was der scheiß soll nur wie soll. Nur wie herausfinden, ich wüsste nicht einmal wo ich mit der Suche anfangen sollte vor allem weil der clang/LLVM kein Problem zu haben scheint.

 *Klaus Meier wrote:*   

> Conftest hatte ich auch mal, dass das geklemmt hat. Habe ich mit kill abgeschossen und dann ging es ohne Probleme weiter.

 

Das habe ich auch versucht aber der Prozess ließ sich selbst mit Signal 9 nicht mehr abschissen.

----------

## schmidicom

Ohne ein "-pipe" in den CFLAGS baut auch der GCC wieder das Paket ohne den Computer zu killen.

Hoffentlich habe ich jetzt wenigstens einen brauchbaren "Workaround"...

----------

## franzf

-pipe hat halt den Nachteil, dass er mit temporären Dateien arbeitet, und bei langsamen Festplatten kann sich das schon arg in die Länge ziehen.

Ich verstehe allerdings auch nicht, was bei diesen Hängern am Ende der Auslöser ist. Mir hat vor ein paar Tagen das Bauen kde-plasma/plasma-desktop den Rechner gefreezed. Nur: gcc hat den reproduzierbar mehrmals gebaut, ohne den Desktop in die Knie zu zwingen - sogar mit gleichzeitig geöffnetem firefox. Und dann vom einen zum anderen Mal geht gar nix mehr! clang hat gar keine Probleme: Der kompiliert durchgehend mit weniger Ressourcenverbrauch und gleichzeitig schneller (selbst bei Paketen, die der gcc anstandslos durchbringt).

Auf meinem Laptop kompilier ich mittlerweile alles "mit Anspruch" mit clang:

```
$ grep clang /etc/portage/package.env 

app-text/qpdfview clang.conf

dev-lang/rubinius clang.conf

dev-qt/* clang.conf

net-libs/webkit-gtk no_debug.conf clang.conf

media-gfx/inkscape no_debug.conf clang.conf

x11-themes/virtuality clang.conf

sys-devel/llvm clang.conf no_debug.conf

sys-devel/clang clang.conf

kde-plasma/* clang.conf

kde-frameworks/* clang.conf

kde-apps/* clang.conf
```

Und alles läuft sogar  :Wink:  (wird dem clang ja beizeiten nachgesagt, dass er zwar kompiliert aber die Programme nicht ausführbar sein sollen)

----------

## Klaus Meier

Das klingt ja interessant. Werde ich mir heute abend mal anschauen. Gibt es schon irgend etwas über die Dateigröße und die Performance? Ich habe es mir mal auf Phoronix angesehen, bei den meisten Sachen nimmt es sich ja nicht viel, aber bei einigem ist die Performance katastrophal. Wichtig ist da ja auch eher die Dateigröße, die meiste Zeit wartet man ja mehr auf die rödelnde Platte als dann auf die tatsächliche Ausführung. Und die wird aktuell von Version zu Version größer.

Fühlt sich das System dadurch anders an?

----------

## Josef.95

 *schmidicom wrote:*   

> Ohne ein "-pipe" in den CFLAGS baut auch der GCC wieder das Paket ohne den Computer zu killen.
> 
> Hoffentlich habe ich jetzt wenigstens einen brauchbaren "Workaround"...

 

Ja, dann wird es wahrscheinlich immer noch an zu wenig virtuellen Speicher liegen.

Ich verstehe aber auch nicht warum du dich so sehr sträubst ein wenig SWAP mit bereitzustellen..

----------

## Klaus Meier

 *Josef.95 wrote:*   

> Ich verstehe aber auch nicht warum du dich so sehr sträubst ein wenig SWAP mit bereitzustellen..

 

Würde ich bei einer SSD auch nicht machen, da können dann enorme Daten geschrieben werden. Obwohl, wenn /var/tmp/portage auf der SSD liegt und man ohne -pipe arbeitet, ist es eh egal.

----------

## schmidicom

Nach allem was ich im Internet gelesen habe ist eine swap pures Gift für eine SSD, deshalb versuche ich das wenn möglich zu vermeiden. Außerdem dürfte zu wenig Speicher, meiner Meinung nach, nicht gleich zum freeze oder hardoff führen sondern höchsten zum Abbruch des Kompiliervorgangs. Genauso seltsam finde ich das ein conftest aus dem GCC-Paket sich dermaßen aufhängen kann das er nicht einmal mehr mit SIGKILL beendet werden kann.

Mag sein das meine Konfiguration nicht der Norm entspricht aber wenn der LLVM damit klar kommt und der GCC nicht glaube ich kaum das man den Fehler wirklich bei mir suchen sollte.

----------

## franzf

 *Klaus Meier wrote:*   

> Das klingt ja interessant. Werde ich mir heute abend mal anschauen. Gibt es schon irgend etwas über die Dateigröße und die Performance? Ich habe es mir mal auf Phoronix angesehen, bei den meisten Sachen nimmt es sich ja nicht viel, aber bei einigem ist die Performance katastrophal. Wichtig ist da ja auch eher die Dateigröße, die meiste Zeit wartet man ja mehr auf die rödelnde Platte als dann auf die tatsächliche Ausführung. Und die wird aktuell von Version zu Version größer.
> 
> Fühlt sich das System dadurch anders an?

 

Das System fühlt sich anders an - es gibt beim Kompilieren keine Hänger mehr  :Wink:  Auch der Lüfter dreht weniger oft auf Anschlag...

Der Desktop an sich scheint auch nicht anders zu laufen. Ich hatte plasma/kde 5 ja bereits früher installiert, und damals noch alles mit gcc kompiliert. Damals gab es deutlich mehr Probleme  :Wink:  Einige Probleme haben die KDE/Qt Devs bereinigt, manche scheint es noch zu geben. Ich gehe davon aus, dass meine Probleme also NICHT mit clang zu tun haben...

Auch inkscape funktioniert tadellos. 

Programme, bei denen ich selber im Quelltext rumfummel, (oder zumindest regelmäßig den Fortschritt beobachte) werden seit einiger Zeit auch mit clang kompiliert (otter, qupzilla, neovim(-qt), qpdfview, YouCompleteMe, ...). Und das geht auch alles (mittlerweile) reibungslos...

Bezüglich der Performance-Probleme: Das liegt einzig und allein daran, dass clang/llvm (noch) keine OpenMP-Implementierung mitbringt. Dadurch fehlt die Parallelisierung, das Programm läuft nur in einem Thread. Speziell auf stärkeren Rechnern mit mehreren (virtuellen) Kernen führt OpenMP zu deutlichen Performancesteigerungen. Aber keine Sorge - daran wird gearbeitet. In diesem Jahr könnte es soweit sein  :Smile: 

----------

## schmidicom

@franzf

Bist du sicher das der llvm, auch in der aktuellen Version (z.B. 3.5.1), noch kein OpenMP kann?

http://clang-omp.github.io/

----------

## franzf

 *schmidicom wrote:*   

> @franzf
> 
> Bist du sicher das der llvm, auch in der aktuellen Version (z.B. 3.5.1), noch kein OpenMP kann?
> 
> http://clang-omp.github.io/

 

Ja, ich bin mir ziemlich sicher  :Smile: 

Das was du da verlinkst ist das offizielle Repo in dem intel (evtl. auch andere) den OpenMP-Support implementieren. Das ist aber NICHT das offizielle LLVM-Repo. Und solange es nicht offiziell ist bekommst du das auch nicht mit den Release-tarballs  :Wink: 

----------

## schmidicom

Dann sind folgende Files vermutlich nur der Anfang "OpenMP" zu implementation, oder sehe ich das Falsch?

```
~ $ equery f llvm | grep -i openmp

/usr/include/clang/AST/DeclOpenMP.h

/usr/include/clang/AST/OpenMPClause.h

/usr/include/clang/AST/StmtOpenMP.h

/usr/include/clang/Basic/OpenMPKinds.def

/usr/include/clang/Basic/OpenMPKinds.h
```

----------

## Klaus Meier

Na warten wir mal ab,  der gcc 5 sieht ja auch ziemlich lecker aus. Der soll beim Kompilieren schneller sein und der erzeugte Code auch verglichen mit dem 4.9.

Das was ich so auf Phoronix gelesen habe und auch selber getestet, war nicht so der Hit. Der erzeugte Code ist stellenweise um den Faktor drei langsamer. Und da selbst auf meiner lahmen Kiste der gcc keine Probleme macht, bleicht dann zum Vergleich nur die Performance übrig. Was ich getestet habe:

mariabdb: Kompilierzeit 19 Minuten gegenüber 15 Minuten. Der vom clang erzeugte Code war etwas kleiner.

lame: Der vom clang erzeugte code war etwas größer und 30% langsamer.

firefox: Belegt zur Laufzeit 10% mehr Speicher.

Also da warte ich lieber 25% länger beim Kompilieren, wenn der erzeugte Code hinterher besser ist. Bei Entwicklern sieht das natürlich genau anders rum aus. Für die ist erst mal wichtig, dass der Code erzeugt wird. Beschleunigen kann man später immer noch.

Also dran bleiben und abwarten, wie sich der nächste clang im Vergleich zum gcc 5 schlägt. Ich stelle mir gerade meinen nächsten Rechner zusammen. Da sind 16GB Speicher eingeplant. Kostet ja kaum noch was und dann kann man komplett im RAM kompilieren. Damit sollte das Thema durch sein.

Edit: So wie es aussieht kommt ja bald llvm 3.6 und alles was ich bislang dazu gefunden habe, ist dass man immer noch hofft, dass OpenMP drin ist. Sorry, aber ohne bringt es einfach nichts. Und die Entwickler vom llvm haben keinen Bock auf OppenMP und es wird dann von Intel dran geklatscht. Klingt jetzt nicht so prickelnd.

----------

## franzf

 *schmidicom wrote:*   

> Dann sind folgende Files vermutlich nur der Anfang "OpenMP" zu implementation, oder sehe ich das Falsch?
> 
> ```
> ~ $ equery f llvm | grep -i openmp
> 
> ...

 

openmp.llvm.org ist mMn. die zuverlässigste Quelle für den aktuellen Status. planet.clang.org kannst du auch mitlesen, da steht "vielleicht mit 3.6, wenn die Reviews schnell genug laufen".

Für welchem Zweck diese Header installiert werden - k.A. Vielleicht von nem früheren Versuch, vielleicht geht ein kleines Subset schon, vielleicht ist es ne Implementierung, damit openmp-Code kompiliert, am Ende wirds aber nicht parallelisiert sondern läuft sequentiell in einem Thread. Oder sonst was  :Wink:  Man könnte jetzt das subversion Repo auschecken (oder sich mit dem Web-Frontend rumquälen) und sich die History der einzelnen Dateien anschauen, dann kommt man wohl am ehesten zu nem korrekten Schluss  :Wink: 

----------

## Josef.95

@schmidicom

naja, wenn du deine SSD nur schonen möchtest könntest du SWAP auf einem anderen Laufwerk bereitstellen.

Ich denk diese Modeerscheinung möglichst gar kein SWAP bereitzustellen ist ne schlechte Idee, damit macht man es dem Kernel nicht einfach noch korrekt zu funktionieren.

Hier baute boost bisher selbst neben einem laufenden kde mit ein wenig SWAP auch auf Rechnern mit nur 2GB RAM bisher immer einwandfrei (zuletzt mit gcc-4.8.3,4).

Und bezüglich möglichst kein SWAP auf ner SSD: Ich denk das trifft auf halbwegs aktuelle SSDs nicht mehr zu - die kann man inzwischen wie ne ganz normale HDD nutzen  :Smile: 

btw Ich musste neulich ein Windows 7 auf einem Rechner mit 32GB RAM und SSD installieren - dort hat Windows sich etwa 25 GB als SWAP auf der SSD reserviert  :Wink:  (gut das hat sich dort durch "Ruhezustand deaktivieren" verringern lassen)

Ich denk es ist einfach keine gute Idee keinen SWAP bereitzustellen.

----------

## franzf

Man kann das AFAIK auch per swapfile lösen. Dadurch wird nicht immer in die selbe Region (Partition) der Platte geschrieben.

Aber evtl. schätze ich diese Technologie auch falsch ein - hab wenig Ahnung und Null praktische Erfahrung mit SSD. Liegt auch daran, dass ich meine Systeme brauche und die immer noch sporadisch autretenden Horrogeschichten von vollständigem Datenverlust schrecken doch ziemlich ab  :Wink:  (Jaja, backup... Aber einen kreativen Schub VOR nem Backup verlieren ist böse und mag ich nicht)

----------

## Josef.95

franzf,

bei den SSDs wird wahrscheinlich nicht immer der gleiche Bereich (einer Partition) beschrieben. Vermutlich wird der interne Controller und Firmware schon dafür sorgen dass die Zellen gleichmäßig "abnutzen"

Wenn dem nicht so wäre, dann wäre Partitionieren allein schon "ungünstig"  :Wink: 

----------

## schmidicom

Es gab mal eine ct'uplink zu dem Thema wie SSD's arbeiten und gemäß diesem Bericht spielt es keine Rolle wo eine Partition liegt oder wie groß diese ist da sich hinten herum der Inhalt trotzdem über den ganzen Speicher verteilt und nur der interne Controller weiß wo was liegt. Daher dürfte es zwischen einer swap-Datei und swap-Partition wohl auch kaum einen wirklichen unterschied geben.

Aber ich werde jetzt mal beim Laptop, zum testen, eine swap-Datei erstellen und hoffen das ich mir dadurch nicht nächstens eine neue SSD kaufen muss.

EDIT:

Tja, das mit der swap-Datei hat sich gerade erledigt weil das auf einer Partition mit btrfs scheinbar nicht geht:

 *https://wiki.archlinux.org/index.php/swap#Swap_file wrote:*   

> Warning: Btrfs does not support swap files. Failure to heed this warning may result in file system corruption. While a swap file may be used on Btrfs when mounted through a loop device, this will result in severely degraded swap performance.

 

Wenn ich dann mal irgendwann Bock habe versuche ich die Partition zu verkleinern und mache mir so eine swap-Partition...

----------

## Josef.95

Tja, hättest es mal gleich so gemacht wie im Gentoo-Handbuch beschrieben  :P 

(sorry, den konnt ich mir grad nicht verkneifen :))

----------

## Klaus Meier

Startest du gparted von der SystemRescueCD (ist kurzem sogar im portage, genial!), da ist das Verkleinern einer Partition doch eine Kleinigkeit.

Ansonsten würde ich da eventuell etwas an der Hardware drehen. Also zum einen, kannst du den Speicher erweitern? Und wenn du USB3 hast, könntest du auch eine externe Platte anschließen. Ist vielleicht billiger als eine neue SSD. Ob du es nun mit Swap arbeitest oder mit /var/tm/portage und das noch ohne -puipe auf der SSD kommt irgendwie auf das Gleiche raus. Stressen tust du sie in beiden Fällen.

----------

## schmidicom

Ist bereits so geschehen, mit der SystemRescueCD war es eine Sache von 5min die root Partition zu verkleinern und eine swap Partition zu erstellen. Ob es hilft kann ich noch nicht sagen aber selbst wenn es hilft ist es meiner Meinung nach ein ganz klarer Bug wenn das ganze System wegen sowas bachab geht.

EDIT:

Ich will es jetzt zwar nicht beschreien aber es könnte sein das sich der GCC mit Swap nicht mehr aufhängt...

----------

