[Tcl-bugs] [ expect-Bugs-883485 ] dejagnu fails during gcc testsuite

[SourceForge.net <no...@so...>]

Bugs item #883485, was opened at 2004-01-24 00:59
Message generated for change (Comment added) made by libes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113179&aid=883485&group_id=13179

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Post (markkp)
Assigned to: Nobody/Anonymous (nobody)
Summary: dejagnu fails during gcc testsuite

Initial Comment:
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


----------------------------------------------------------------------

>Comment By: Don Libes (libes)
Date: 2005-08-30 14:29

Message:
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


----------------------------------------------------------------------

Comment By: miguel sofer (msofer)
Date: 2005-08-30 14:15

Message:
Logged In: YES 
user_id=148712

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

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2005-08-30 11:12

Message:
Logged In: NO 

See
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=43310
for an expect testcase

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2005-07-29 19:10

Message:
Logged In: YES 
user_id=79902

me too

----------------------------------------------------------------------

Comment By: Don Libes (libes)
Date: 2005-07-29 18:17

Message:
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.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2005-07-29 18:10

Message:
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...

----------------------------------------------------------------------

Comment By: Don Libes (libes)
Date: 2005-07-19 14:39

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=113179&aid=883485&group_id=13179