Re: [package - 130arm64-default][lang/gcc12-devel] Failed for gcc12-devel-12.0.1.s20220306_2 in build/runaway
- Reply: Mark Millard : "Re: [package - 130arm64-default][lang/gcc12-devel] Failed for gcc12-devel-12.0.1.s20220306_2 in build/runaway"
- In reply to: Dimitry Andric : "Re: [package - 130arm64-default][lang/gcc12-devel] Failed for gcc12-devel-12.0.1.s20220306_2 in build/runaway"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 26 Mar 2022 19:35:20 UTC
On 2022-Mar-26, at 07:26, Dimitry Andric <dim@FreeBSD.org> wrote: > On 26 Mar 2022, at 15:16, pkg-fallout@freebsd.org <pkg-fallout@FreeBSD.org> wrote: >> >> You are receiving this mail as a port that you maintain >> is failing to build on the FreeBSD package build server. >> Please investigate the failure and submit a PR to fix >> build. >> >> Maintainer: toolchain@FreeBSD.org >> Log URL: http://ampere3.nyi.freebsd.org/data/130arm64-default/60ab72786154/logs/gcc12-devel-12.0.1.s20220306_2.log >> Build URL: http://ampere3.nyi.freebsd.org/build.html?mastername=130arm64-default&build=60ab72786154 > > So there isn't any actual error message in this log, except at the end: > > ... > =>> Cleaning up wrkdir > ===> Cleaning for gcc12-devel-12.0.1.s20220306_2 > Killed > build of lang/gcc12-devel | gcc12-devel-12.0.1.s20220306_2 ended at Sat Mar 26 14:16:58 UTC 2022 > build time: 12:31:35 > !!! build failure encountered !!! > > It looks like the last command being run before "Killed" is the cc1plus > executable being linked with LTO, so I am assuming the build is killed > due to an out-of-memory condition? > > But this is only visible to people that have access to the machine the > poudriere instance is running on. Can somebody with access please check? > I do not have access but I've started a poudriere build of my own on a HoneyComb. I've a patched top that monitors and reports various Maximum Observed (MaxObs????) figures, 64 GiBytes of RAM and slightly over 246 GiBytes of swap. So hopefully it will report on about how big the memory use gets. But it is allowed to use all 16 cores and there will be no competing bulk builds using resources. So not a match to the build server context. Note: It is a ZFS context, so MaxObsWired is normally large and shrinks over times where memory needs to be used for other things. So the primary memory figures would be: MaxObsSwapUsed (if any) MaxObsActive MaxObs(Act+Lndry+SwapUsed) Side Note: http://ampere3.nyi.freebsd.org/build.html?mastername=130arm64-default&build=60ab72786154 reports a Time of 11:48:41 but the log reports "build time: 12:31:35". My guess is that processing the log file for extracting the type of error makes some (much?) of the difference. (Type being runaway_process in this case.) === Mark Millard marklmi at yahoo.com