https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344
Bug ID: 108344
Summary: Many tests time out: isatty called in a tight loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee: gaius at gcc dot gnu.org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
Build: i386-pc-solaris2.11
I'm seeing a very weird error running the m2 testsuite on Solaris/x86: quite
a number of tests time out in compilation. However, this only happens when
gcc is configured to use /bin/as, not with gas. Besides, the timeouts affect
only 64-bit compiltions. I'm seeing this with both flex 2.5.35 and 2.6.4.
Here's what I observe: for the affected tests, is in a tight loop like this:
12901: /var/gcc/regression/master/11.4-gcc/build/gcc/cc1gm2 -fcpp-begin -E -l
fabbd4c7 ioctl (0x6, 0x0, 0x1032, 0x8c15c33) + 7
08c15c87 yy_init_buffer(yy_buffer_state*, __FILE*) (0xadce188, 0xadce189,
0xfeff9778, 0xadce188, 0x0, 0xadce189) + 67
08c15d17 yyrestart(__FILE*) (0xad29110, 0x1, 0x2000, 0xad29110, 0x14,
0xadcbb60) + 27
08c18918 yylex() (0xad6c320, 0xfeff97f0, 0xfeff97f8, 0x8c4e16f, 0x2a, 0x1) +
2668
08c18b9c m2flex_GetToken (0x2a, 0x1, 0xfeff9808, 0x8c4e16f, 0xadd4d58, 0x2a) +
3c
08c4e16f M2LexBuf_GetToken (0x1, 0xfeff983c, 0xfeff9858, 0x8c347cd, 0xadd3750,
0x2a) + 3f
08c4ebe5 M2LexBuf_OpenSource (0xadd3750, 0x2a, 0xfeff9858, 0x8c344d8) + 65
08c347cd M2Comp_compile (0xfeffa662, 0x43, 0x36, 0xad33290) + 3fd
08bea500 gm2_langhook_parse_file() (0x3, 0xf9e09000, 0xfeff9948, 0x92a78d7,
0x43, 0x0) + 60
092a442d compile_file() (0x2, 0x8b3c3de, 0xfeff9948, 0x92a7e34) + 1d
092a78dc toplev::main(int, char**) (0x1000, 0x84ee24f, 0xfae8e310, 0xa4411e1)
+ 136c
0a4411e1 main (0xfeff9c6c, 0xfeff99b4, 0x8be8add) + 31
08be8a46 _start (0x4f, 0xfeff9cee, 0xfeff9d23, 0xfeff9d2f, 0xfeff9d32,
0xfeff9d3c) + 46
That ioctl is
ioctl(6, TCGETA, 0xFEFF96E0) Err#25 ENOTTY
no doubt resulting from calls to isatty in the generated gm2-compiler/m2flex.c.
What's even weirder, if I run such a compilation manually, it completes in
about
half a second, and I've not yet managed to reproduce the issue with anything
but
a full make -jN -k check-m2 run. This is pretty tedious because those 600
second
timeouts massively add up, slowing the whole test time tremendously.
I've already tried using flex -B to generate the lexer, but that didn't make
a difference, which judging from the skeleton file is no wonder. However, when
using --never-interactive, things gets way worse: I've already several
instances of cc1gm2 running for 12+ minutes (way beyond the 600 second timeout
of runtest),
making not syscall whatsoever. All this suggests that something is very weird
in the m2 lexer somewhere.
Here's the list of affected tests (all in gm2/iso/pass, doesn't change between
runs):
addadr1.mod
bits32c.mod
callwraptime.mod
caseiso.mod
caseiso2.mod
cast.mod
cast3.mod
castiso.mod
ChanConsts.mod
const1.mod
constreal.mod
constructor1.mod
constructor2.mod
constructor3.mod
constructor4.mod
constructor5.mod
constructor6.mod
constsize4.mod
ConvTypes.mod
delim.mod
delim2.mod
enummodule.mod
except1.mod
expproc.mod
expproc2.mod
isob.mod
isobitset.mod
isobitset2.mod
longm.mod
m.mod
proccast.mod
realbitscast.mod
set12.mod
stringchar.mod
subassign.mod
testaddindr.mod
testconv.mod
testconv2.mod
testconv3.mod
testconv4.mod
testconv5.mod
testconv6.mod
testconv7.mod
testconv8.mod
testconv9.mod
testiso.mod
testiso2.mod
testisosize.mod
testlength.mod
testlength2.mod
testlength3.mod
testlength4.mod
testlength5.mod
unbounded.mod
unbounded2.mod
