dejagnu
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Curious "buffer_full" line within host_execute


From: David Malcolm
Subject: Curious "buffer_full" line within host_execute
Date: Thu, 09 Oct 2014 14:49:26 -0400

I've been attempting to debug an issue with a dg-based testsuite for a
new gcc feature I'm working on:
  https://gcc.gnu.org/wiki/JIT
but am somewhat stumped.

I'm getting a tcl traceback (see attached jit.log) when running gcc's
"make check", but not "make check-jit": it runs OK when invoking just
the latter.  I can also trigger the traceback by running:

  make check-gcc check-jit -j64

but not just:

  make check-jit -j64

If I run them in separate terminals:

  T1: make check-gcc -j64
  T2: make check-jit -j64

then "make check-jit" succeeds.

As I understand it, the makefile is kicking off multiple "runtest --tool
TOOL" invocations, with different values of TOOL, all sharing the same
ultimate stdout/stderr, AIUI - so presumably all that's different is the
load on the system, and perhaps significantly, the stdout/stderr being
shared by the two invocations.

By adding lines of the form 
   'pass "got here 001"' 
to try to isolate the problem, the problem seems to relate to line 116
below in dejagnu.exp's host_execute:

   107  proc host_execute {args} {
   108      global text
   109  
   110      set timeoutmsg "Timed out: Never got started, "
   111      set timeout 100
   112      set file all
   113      set timetol 0
   114      set arguments ""
   115  
>>>116      expect_before buffer_full { perror "Buffer full" }
   117  

which seems to have been in dejagnu.exp since the earliest version in
git (from 2001):
http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commitdiff;h=ad5950c28155a9583b19cff68d3e7546d126c5f2

Taking it out fixes the problem.

Interestingly, in the log attached, the problem seems to reliably occur
the *second* time this line is reached; the "pass" messages indicate
that the first time host_execute is called, execution makes it all the
way through to returning from host_execute and back to my jit.exp.

I've been digging through the source to expect, and I note that
expect.c:parse_expect_args has "full_buffer", rather than "buffer_full":

   577              /*
   578               * We have a pattern or keyword.
   579               */
   580  
   581              static char *keywords[] = {
>>>582                  "timeout", "eof", "full_buffer", "default", "null",
   583                  (char *)NULL
   584              };
   585              enum keywords {
   586                  EXP_ARG_TIMEOUT, EXP_ARG_EOF, EXP_ARG_FULL_BUFFER,
   587                  EXP_ARG_DEFAULT, EXP_ARG_NULL
   588              };

which makes me wonder if this code has ever worked as intended, or if
I'm misreading things.

Any hints as to what might trigger the traceback, or how to debug
further?  (e.g. how to get the full error message back) 
(I'm a relative newcomer to tcl, expect, and dejagnu).

Am attaching full "jit.log".

My jit.exp can be seen at:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/testsuite/jit.dg/jit.exp;h=4672063b00313d3195e88e23fdc591ad63110ee7;hb=refs/heads/dmalcolm/jit

This is with:
  expect-5.45-10.fc20.x86_64
  dejagnu-1.5.1-3.fc20.noarch
  tcl-8.5.14-1.fc20.x86_64
on a Fedora 20 box.

Thanks

Dave

Attachment: jit.log
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]