From: SourceForge.net <no...@so...> - 2005-09-11 12:47:23
|
Bugs item #883485, was opened at 2004-01-23 21:59 Message generated for change (Comment added) made by nobody 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: Nobody/Anonymous (nobody) Date: 2005-09-11 05:47 Message: 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. ---------------------------------------------------------------------- Comment By: Don Libes (libes) Date: 2005-08-30 11: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 11: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 08: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 16:10 Message: Logged In: YES user_id=79902 me too ---------------------------------------------------------------------- Comment By: Don Libes (libes) Date: 2005-07-29 15: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 15: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 11: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 |