There seems to be a (timing?) bug in gawk v3.1.2 (ebuild -r3) (see attachement for code to reproduce). compilers tried: gcc-2.95.3 (-O2), gcc-3.2.2 (-O2 and -O1). gawk v3.1.1 (ebuild -r2) worked without trouble. see also: http://mail.gnu.org/archive/html/bug-gnu-utils/2003-04/msg00043.html (the code in the attach is taken from that msg too). I've seen this error also with "dev-util/arch" when doing "larch what-changed" on a particular src-tree. Reproducible: Always Steps to Reproduce: run the attachment, wait a few seconds, boooom Actual Results: gawk: cmd. line:2: fatal: grow_iop_buffer: iop->buf: can't allocate -2147483646 bytes of memory (Cannot allocate memory)
Created attachment 12840 [details] code to reproduce
After the last masking of 3.1.2 I first thought it was due to this report and did not check the bug-id -- but then 3.1.2 came back in stable :( Please check this out. Tested with gcc-2.95.3 and gcc-3.2.2 on gentoo -- same result for both. Thomas
Hi, the response-time to bug-report is a bit frustrating -- I can understand that for enhancements and minor bugs but not for something like _this_. If there wasn't that bug in portage that prevents "pinning" of apps in the personal world-file it wouldn't be _that_ annoying :( Thomas
Hey Azarah, not sure what the status on gawk upstream is, there are now 2 critical bugs in the 3.1.2 release that we know of... last time 3.1.2 was masked however it caused issues (bootstrap stopping issues) so please take a look at this and advise. Thomas: Yes the response time has been significant, unfortunately we are stuck between a rock and a hard place on this bug because as I mentioned above there are critical bugs in this release version, and appear to be compatibility issues with downgrading stable gentoo to 3.1.1, calm down.
OK. If upstream still has the problem, could we construct a workaround with 2 SLOTs of gawk: one for portage with 3.1.2 (as the bugs doesn't seem to bite it) and one for "normal use" with 3.1.1 ? Thomas
Tested gawk-3.1.3.ebuild with the code from the attachment above and one other application that crashed frequently with 3.1.2 => at least regarding this bug 3.1.3 behaves well.
Sorry, pretty tied up currently, and mail down again :/ Anyhow, what is the take on this ? Think we can unmask 3.1.3 ?
I encountered no problems using 3.1.3 so far -- using it for a few days now. I'd unmask it -- it fixes this known bug so we can discover new ones :|
Lolo unmasked 3.1.3 for x86 and other arch devs will follow.
For the record, this bug also exists on Alpha. With next command it's not always reproducable: TRACKS=`cdparanoia -Q 2>&1 |awk -F. '/^ [ 0-9][0-9]\./ {printf "%02d\n",$1}'` awk: cmd. line:1: (FILENAME=- FNR=26) fatal: grow_iop_buffer: iop->buf: can't allocate 1073741826 bytes of memory (Cannot allocate memory) The problem went away went added a grep like this: TRACKS=`cdparanoia -Q 2>&1 | grep '^ [ 0-9][0-9]\.' |\ awk -F. '/^ [ 0-9][0-9]\./ {printf "%02d\n",$1}'` I just tried attachment (id=12840) and I also get this bug, but with a positive number: gawk: cmd. line:2: fatal: grow_iop_buffer: iop->buf: can't allocate 1073741826 bytes of memory (Cannot allocate memory)
