Menu
▾
▴
#25 dejagnu fails during gcc testsuite
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
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...
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
Logged In: NO
See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=43310
for an expect testcase
Logged In: YES
user_id=148712
That testcase executes without error here (Tcl8.4.7, Expect
5.42.1, ubuntu hoary).
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.
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