public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "ro at gcc dot gnu.org" <gcc-bugzilla@gcc.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	[thread overview]
Message-ID: <bug-108344-4@http.gcc.gnu.org/bugzilla/> (raw)

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

             reply	other threads:[~2023-01-09 15:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09 15:12 ro at gcc dot gnu.org [this message]
2023-01-09 15:12 ` [Bug modula2/108344] " ro at gcc dot gnu.org
2023-01-13 13:01 ` ro at CeBiTec dot Uni-Bielefeld.DE
2023-04-26  6:57 ` rguenth at gcc dot gnu.org
2023-05-16 14:52 ` cvs-commit at gcc dot gnu.org
2023-05-16 14:59 ` gaius at gcc dot gnu.org
2023-05-16 15:04 ` gaius at gcc dot gnu.org
2023-06-14 12:36 ` ro at gcc dot gnu.org
2023-07-28 21:51 ` cvs-commit at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-108344-4@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).