NetBSD Problem Report #34442
From heas@shrubbery.net Thu Aug 31 23:34:29 2006
Return-Path: <heas@shrubbery.net>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by narn.NetBSD.org (Postfix) with ESMTP id 93DE963B973
for <gnats-bugs@gnats.NetBSD.org>; Thu, 31 Aug 2006 23:34:29 +0000 (UTC)
Message-Id: <20060831223425.D8F6986552@guelah.shrubbery.net>
Date: Thu, 31 Aug 2006 22:34:25 +0000 (UTC)
From: heas@shrubbery.net
Reply-To: heas@shrubbery.net
To: gnats-bugs@NetBSD.org
Subject: lang/tcl-expect deadlock on solaris/linux
X-Send-Pr-Version: 3.95
>Number: 34442
>Category: pkg
>Synopsis: lang/tcl-expect deadlock on solaris/linux
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: pkg-manager
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Aug 31 23:35:00 +0000 2006
>Closed-Date: Sun May 15 02:00:48 +0000 2022
>Last-Modified: Sun May 15 02:00:48 +0000 2022
>Originator: john heasley
>Release: NetBSD 3.99.17
>Organization:
>Environment:
System: NetBSD guelah 3.99.17 NetBSD 3.99.17 (guelah) #1: Tue Apr 18 01:51:21 UTC 2006 root@oak:/sys/arch/sparc64/compile/guelah sparc64
Architecture: sparc64
Machine: sparc64
>Description:
tcl-expect on linux/solaris can deadlock. What happens is data arrives on a
"channel" (eg: pty), your script consumes a portion of that data, then the
expect (the input matching loop) is continued on the existing buffer which
still has data. No new data is available from the channel, but read(2) is
called and we block instead of offering the contents of the buffer to the
expect.
If the process expect is communicating with happens to have reached a
prompting point, it will be waiting for input from expect and we deadlock,
because expect is also waiting for input from the process.
This does not occur on *BSD.
>How-To-Repeat:
The problem is very timing sensitive. It is most prevalent when the network
is fast and the machine running RANCID is slow/loaded.
>Fix:
To hack this, I just added a poll() for readability. This hack has fixed
every complaint I've received from users of RANCID on linux/solaris.
ftp://ftp.shrubbery.net/pub/rancid/expect-hack2
The comments in exp_chan.c suggest that the file descriptor should be
non-blocking. My original hack was to just set it to be non-blocking. That
works for Linux, but caused problems with one of solaris' streams that would
bugger the user's terminal when expect exited.
Because the poll hack works and the tcl code is ugly, i've not expended any
effort to find the actual bug, which I believe is somewhere in Tcl.
I'll leave it to the tcl-expect maintainer to determine if this is appropriate
for pkgsrc. I submitted a bug report to the authors of expect about 4 years
ago, but have not heard from them.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: pkg-manager->jwise
Responsible-Changed-By: snj@netbsd.org
Responsible-Changed-When: Fri, 01 Sep 2006 04:22:17 +0000
Responsible-Changed-Why:
Assign to maintainer.
Responsible-Changed-From-To: jwise->pkg-manager
Responsible-Changed-By: jwise@narn.netbsd.org
Responsible-Changed-When: Thu, 20 Aug 2009 15:55:11 +0000
Responsible-Changed-Why:
I am no longer MAINTAINER for this package.
State-Changed-From-To: open->suspended
State-Changed-By: obache@NetBSD.org
State-Changed-When: Fri, 21 Aug 2009 10:55:55 +0000
State-Changed-Why:
Originator request decision of the MAINTAINER,
but pkgsrc does not have the maintainer of the package anymore.
From: john heasley <heas@shrubbery.net>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org,
obache@NetBSD.org, heas@shrubbery.net
Subject: Re: pkg/34442 (lang/tcl-expect deadlock on solaris/linux)
Date: Fri, 21 Aug 2009 10:08:10 -0700
Fri, Aug 21, 2009 at 10:55:56AM +0000, obache@NetBSD.org:
> Synopsis: lang/tcl-expect deadlock on solaris/linux
>
> State-Changed-From-To: open->suspended
> State-Changed-By: obache@NetBSD.org
> State-Changed-When: Fri, 21 Aug 2009 10:55:55 +0000
> State-Changed-Why:
> Originator request decision of the MAINTAINER,
> but pkgsrc does not have the maintainer of the package anymore.
>
Can I apply this myself? There is no protocol when the package doesn't
have a maintainer, right?
From: "OBATA Akio" <obache@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/34442 (lang/tcl-expect deadlock on solaris/linux)
Date: Sat, 22 Aug 2009 09:52:22 +0900
On Sat, 22 Aug 2009 04:10:04 +0900, john heasley <heas@shrubbery.net> wrote:
> Can I apply this myself? There is no protocol when the package doesn't
> have a maintainer, right?
Basically, this GNATS DB handle packaging problems for pkgsrc, not orignal source bugs.
But if the bug and its workaround is clear, it may be acceptable, but should be also accepted by upstream.
(it will be not welcomed that someone report pkgsrc local patch related problems to upstream)
If the maintainer exists, he/she may coordinate the bug with upstream.
From: john heasley <heas@shrubbery.net>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org,
heas@shrubbery.net
Subject: Re: pkg/34442 (lang/tcl-expect deadlock on solaris/linux)
Date: Sat, 22 Aug 2009 19:04:19 +0000
Sat, Aug 22, 2009 at 12:55:02AM +0000, OBATA Akio:
> Basically, this GNATS DB handle packaging problems for pkgsrc, not orignal source bugs.
> But if the bug and its workaround is clear, it may be acceptable, but should be also accepted by upstream.
> (it will be not welcomed that someone report pkgsrc local patch related problems to upstream)
> If the maintainer exists, he/she may coordinate the bug with upstream.
I doubt that this patch would be accepted by the authors, and rightly so.
The bug that this works around lies, I believe, in tcl not expect and
AFAIK exists only on Linux and Solaris, likely within either pty or signal
handling. The hack and description of the bug had been submitted to them
literally years ago, so they've had opportunity to fix it. However, I am
not willing to spend my little spare time debugging the ugly code of either
tcl or expect to fix it properly. It remains an effective hack.
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: heas@shrubbery.net
Subject: Re: pkg/34442 (lang/tcl-expect deadlock on solaris/linux)
Date: Mon, 15 Feb 2010 22:01:44 +0000
On Sat, Aug 22, 2009 at 12:55:02AM +0000, OBATA Akio wrote:
> > Can I apply this myself? There is no protocol when the package doesn't
> > have a maintainer, right?
>
> Basically, this GNATS DB handle packaging problems for pkgsrc, not
> orignal source bugs. But if the bug and its workaround is clear,
> it may be acceptable, but should be also accepted by upstream. (it
> will be not welcomed that someone report pkgsrc local patch related
> problems to upstream) If the maintainer exists, he/she may
> coordinate the bug with upstream.
We also take reasonable patches that fix real problems if upstream is
comatose, if someone's willing to take the time to prepare them.
Other than cosmetic issues (specifically, don't reuse bytesRead for
the return value of poll, declare some other integer) I don't see any
reason we shouldn't apply this.
--
David A. Holland
dholland@netbsd.org
State-Changed-From-To: suspended->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 29 Dec 2014 08:49:06 +0000
State-Changed-Why:
Does this problem still exist with the current version of tcl?
(and of tcl-expect)
From: heasley <heas@shrubbery.net>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org,
dholland@NetBSD.org, heas@shrubbery.net
Subject: Re: pkg/34442 (lang/tcl-expect deadlock on solaris/linux)
Date: Mon, 29 Dec 2014 17:14:27 +0000
Mon, Dec 29, 2014 at 08:49:06AM +0000, dholland@NetBSD.org:
> Synopsis: lang/tcl-expect deadlock on solaris/linux
>
> State-Changed-From-To: suspended->feedback
> State-Changed-By: dholland@NetBSD.org
> State-Changed-When: Mon, 29 Dec 2014 08:49:06 +0000
> State-Changed-Why:
> Does this problem still exist with the current version of tcl?
> (and of tcl-expect)
afaik, yes. No users of Rancid (net/rancid) have complained about the
problem for a while, but we provide the patch and a patched version of
expect on the rancid site and it seems well-known that its necessary.
We no longer use solaris at work, but use the patch on our linux hosts.
We do not use the patch on netbsd or freebsd.
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 29 Dec 2014 20:55:35 +0000
State-Changed-Why:
feedback received; tcl is apparently still broken. (shocking...)
From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/34442 CVS commit: pkgsrc/lang/tcl-expect
Date: Sun, 15 May 2022 01:56:24 +0000
Module Name: pkgsrc
Committed By: dholland
Date: Sun May 15 01:56:24 UTC 2022
Modified Files:
pkgsrc/lang/tcl-expect: Makefile distinfo
Added Files:
pkgsrc/lang/tcl-expect/patches: patch-exp__chan.c
Log Message:
lang/tcl-expect: add workaround for deadlock seen on Linux and Solaris
Closes PR 34442.
To generate a diff of this commit:
cvs rdiff -u -r1.34 -r1.35 pkgsrc/lang/tcl-expect/Makefile
cvs rdiff -u -r1.22 -r1.23 pkgsrc/lang/tcl-expect/distinfo
cvs rdiff -u -r0 -r1.1 pkgsrc/lang/tcl-expect/patches/patch-exp__chan.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 15 May 2022 02:00:48 +0000
State-Changed-Why:
applied, thanks
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.