Date: Sun, 17 Jul 2022 07:34:22 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 265254] lang/gcc11: build gets stuck Message-ID: <bug-265254-29464-t3KDeJsTBk@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265254-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-265254-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265254 Matthias Andree <mandree@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mandree@FreeBSD.org --- Comment #20 from Matthias Andree <mandree@FreeBSD.org> --- So there's some discussion where people are seemingly talking at different levels. Yuri is observing an exploding number of jobs, and if some parent is swapped out under memory pressure - and possibly with ZFS filling up memory and/or disks getting very slow - then the parent process can't collect the children that have exited, hence many <defunct> zombies.=20=20 Grim process reaper caught up in a traffic jam if you will. Then some of the GCC drivers seem to be trying to interact with the GNU make jobservers to avoid that, but either this is not configured (port but, eith= er upstream or FreeBSD's port) or not working in a bootstrap =3D> someone could investigate that and I am not sure off-hand if it pertains to GCC11. I recall that GCC has a hefty discussion when it was introducing LTO that it going slow because you have, say, 16 processes generate code and the LTO li= nk just run one because at that time (again, not sure which linker exactly) the assumption still was that linking is serial, disregarding the "LTO global optimizer and code generation" phases. Then there are fat and thin LTO variants... So it is a complex matter and GCC11 is not the only offender, apparently mongodb50 was recently told not to use LTO in FreeBSD's port factory settin= g, and there is more.=20 I frequently see my builds killed because my many-GB 8-core 2-threads-per-c= ore Ryzen 1700 fills up the disk during compiler builds, and I FREQUENTLY see multiple compilers competing in poudriere.=20 It's one or two LLVMs, one GCC, and Rust at the same time, and then I usual= ly fill up the disk. Especially if anything generates debugging information intermediately without my setting WITHOUT_DEBUG because someone thought it = wise to have -flto -g or something.=20 Python 3.8 did the latter on my mailserver and could not build with 1 GB RA= M + 1 GB swap, but the Python port has since been fixed. So yes, arguably my own FreeBSD builer VM should have more disk space ;-) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265254-29464-t3KDeJsTBk>