If you have sufficient swap space but still get OOM kills that DON'T have a "swap_pager_getswapspace" error, also try increasing vm.pageout_oom_seq a lot. (OOM kills can be triggered not by lack of swap space but by slowness in pageouts)
-
-
Replying to @RhodiumToad
Thanks for the thoughts. I isolated the problem part of the build and ran the compiler directly from the shell. After a while it starts eating core at 50MB/second until its all gone. It's pretty obviously a leak in the compiler somewhere.
1 reply 0 retweets 0 likes -
Replying to @extremecompute @RhodiumToad
Worth mentioning this is a clean CD install of 12.1-R -> check out 12.1-R -> source -> buildworld. Only oddness is /usr/src and /usr/obj on ZFS datasets.
1 reply 0 retweets 0 likes -
Replying to @extremecompute @RhodiumToad
c++ -target x86_64-unknown-freebsd12.1 [...] -c /usr/src/contrib/llvm/tools/clang/lib/ASTMatchers/Dynamic/Registry.cpp -o ASTMatchers/Dynamic/Registry.o
1 reply 0 retweets 0 likes -
Replying to @extremecompute
Can't reproduce. Installed a 12.1 system with zfs in a 3GB bhyve vm, and tried a buildworld at -j4; it's still running (maybe ~45 min to go), but it compiled that file ok
1 reply 0 retweets 1 like -
Replying to @RhodiumToad
Thanks for the experiment. The totally weird thing about this is that it passed that file and then broke on another one later. And repeat. Its like an uninitialised variable is making the results random. Always with llvm/clang though.
2 replies 0 retweets 0 likes -
Replying to @extremecompute @RhodiumToad
FWIW I'm using 1Gb of core and 2Gb of swap (which is hardly touched until it goes bananas). High water mark on c++ is ~300Mb normally (size, not res); only sshd running and built using default(?) -j1.
2 replies 0 retweets 0 likes -
Replying to @extremecompute
Build completed w/o error on 3GB; trying again on 1GB at lower -j settings.
1 reply 0 retweets 1 like -
Replying to @RhodiumToad @extremecompute
Using -j2 at 1GB, build is still running but has built AST/Dynamic/Registry successfully. swap high water mark about 300MB so far. (I'll try -j1 after this is done, but obviously that'll take longer)
2 replies 0 retweets 1 like -
Replying to @RhodiumToad
Well, I've compared the two runs and guess what. The second time it got further. Going for a third, to see whether it's further each time, or random. Most troubling.
1 reply 0 retweets 0 likes
If it's not behaving consistently (assuming you're not using meta mode, or you empty /usr/obj first) then I'd start wondering about hardware issues.
-
-
Replying to @RhodiumToad
It's on a VM. Yes, I'm wondering about "hardware" issues too. The only explanation I have is that there's some initialised data that falls differently on a VM, but at random. I could, of course, build it on something else - but I want to know why this is happening.
1 reply 0 retweets 0 likes -
Replying to @extremecompute @RhodiumToad
Any chance of an MD5 of /usr/src/contrib/llvm/tools/clang/lib/ASTMatchers/Dynamic/Registry.cpp It's that that's blowing things up. It's only ~1000 lines long!
2 replies 0 retweets 0 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.