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:

NetBSD Home
NetBSD PR Database Search

(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.