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:          suspended
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 31 23:35:00 +0000 2006
>Closed-Date:    
>Last-Modified:  Mon Feb 15 22:05:02 +0000 2010
>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

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.