From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 96F183858D38; Mon, 9 Jan 2023 15:12:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 96F183858D38 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1673277134; bh=t11gjZWUHl6Tj3192fgRHNUzkJe+BdYv2KwMAJ2DmoM=; h=From:To:Subject:Date:From; b=Q0W9u3zfR3rRj2zakzIi/uH0qLbVLZWoPbw3oM2ZWh2yaTiUNqFlDql97VgtA0wu1 2o7rl3Q1U2lF0pReTYNE3LjeT7tD2XsRDhVJXzECyiSmhnni9N22DmR/5zmXAl5lEa ggu12zUkBxMt1SuY2UeOq0ojSvmLy5/vWiQawJQg= From: "ro at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug modula2/108344] New: Many tests time out: isatty called in a tight loop Date: Mon, 09 Jan 2023 15:12:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: modula2 X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ro at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: gaius at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone cf_gcchost cf_gcctarget cf_gccbuild Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108344 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 affe= ct 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, 0x2= a) + 3c 08c4e16f M2LexBuf_GetToken (0x1, 0xfeff983c, 0xfeff9858, 0x8c347cd, 0xadd3= 750, 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, 0xa4411= e1) + 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/m2fle= x.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 time= out of runtest), making not syscall whatsoever. All this suggests that something is very we= ird in the m2 lexer somewhere. Here's the list of affected tests (all in gm2/iso/pass, doesn't change betw= een 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=