Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#25 dejagnu fails during gcc testsuite

open
nobody
None
5
2004-01-24
2004-01-24
Mark Post
No

The gcc testsuite fails during "make check" processing
because of a limitation/bug in expect. The problem,
and a proposed fix to expect, is documented in this gcc
bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12096

I have applied the patch to expect 5.38 (with some
adjustments for changed offsets, etc.), and the patch
does fix the problem that is reported.

I can upload a diff file that fits exactly onto 5.38,
if you would like me to do that, or you can just look
at the patch in the URL above.

Thanks,

Mark Post

Discussion

  • Don Libes
    Don Libes
    2005-07-19

    Logged In: YES
    user_id=91284

    This sounds like a bug in Tcl rather than a bug in Expect.
    Here's the comment from the gcc bug report:

    + /* FIXME: If we ask less than what is available in the
    tcl buffer
    + when tcl has seen EOF, we will throw away the
    remaining data
    + since the next read will get EOF. Since expect is
    line-oriented,
    + we exand our buffer to get EOF or the next newline
    at the end of
    + the input buffer. I don't know if it is the right
    fix. H.J. */

    It sounds like it is saying Tcl is delivering an EOF
    indication before it should. No? If so, the fix should be
    to Tcl, not Expect.

    I am further befuddled by this comment because of the
    assertion that Expect is line-oriented. The patch similarly
    takes this stance. But Expect is not line-oriented. There
    is nothing in the original code that gaves \n any special
    weight. So I'm rather confused by this patch.

     
  • Logged In: YES
    user_id=79902

    If you can come up with a way of duplicating the bug in pure
    Tcl (or with a little C helper if you must) we can track
    this inside the core. Right now, it just mystifies me
    because the character reader code appears to me to get all
    the buffer handling right...

    The only things I can think of are silly things like failing
    to check for a blocked channel, but I'd assume that expect
    would get those sorts of things right...

     
  • Don Libes
    Don Libes
    2005-07-29

    Logged In: YES
    user_id=91284

    First, I'd like to see a (simple) Expect script that
    demonstrates the problem. I still don't have any kind of
    handle on what the problem is! I'm just going by the
    comments in the patch.

     
  • Logged In: YES
    user_id=79902

    me too

     
  • miguel sofer
    miguel sofer
    2005-08-30

    Logged In: YES
    user_id=148712

    That testcase executes without error here (Tcl8.4.7, Expect
    5.42.1, ubuntu hoary).

     
  • Don Libes
    Don Libes
    2005-08-30

    Logged In: YES
    user_id=91284

    I just tried that example with Expect 5.43.0 and it worked
    fine - it included the last fragmentary line. Please try
    upgrading.

    Don

     
  • Logged In: NO

    There's a test script at
    http://bugs.linuxfromscratch.org/attachment.cgi?id=132 that
    appears to tickle this bug for me. I couldn't get it to
    reliably fail in as much as I can't pinpoint exactly how
    much data is required to make expect fail to cat the full
    file. Trying './test-expect.sh 1000' should trigger it though.

     
  • Duncan Roe
    Duncan Roe
    2006-06-25

    Logged In: YES
    user_id=684797

    I had to apply the patch to expect-5.43 in order to remove
    spurious error reports for gcc 4.1.1. See
    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28137