The following reply was made to PR kern/32682; it has been noted by GNATS.

From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Wed, 22 Feb 2006 16:47:49 +0100

 Am 02.02.2006 um 15:55 Uhr +0000 schrieb Hauke Fath:
 >  Gnah, when you want the bug, it doesn't show...
 >
 >  A coworker reported it once with a -current kernel though, so it's
 >  not strictly netbsd-3.
 >
 >  Am 31.01.2006 um 17:55 Uhr +0000 schrieb Christos Zoulas:
 >  >  Can you show what w(1) prints and the "interesting" ptys in /dev/[pt]ty??.
 >  >  I suspect what is going on, is that you have a rogue program that is
 >  >  opening old style pty's behind the pty subsystem's back, so when ptyfs
 >  >  tries to open the same pty, it fails.
 >
 >  Sounds reasonable...
 >
 >  >So when it fails for pts/4 for example, what does lsof say for 
 >/dev/{t,p}typ4?
 
 Doesn't look that easy.
 
 I just encountered the bug on an idle machine that I had logged into 
 remotely, i.e. no KDE stuff running (the login prompter is gdm, and 
 there were a few leftover dbus-daemon-1 processes).
 
 Matlab 14 aborted, and a ktrace showed me it wanted /dev/pts/1 but 
 didn't get it. The fstat /dev/{t,p}typ1 came up _empty_.
 
 I opened another remote xterm, became root to install the lsof 
 package. The second login did successfully create /dev/pts/1. After 
 that, Matlab would start up just fine, and create a /dev/pts/2, but 
 owned root:wheel unlike 0 and 1 which were owned by my id, group tty.
 
 Any ideas about where to go from here?
 
 	hauke
 
 
 -- 
 /~\  The ASCII Ribbon Campaign                    Hauke Fath
 \ /    No HTML/RTF in email	        Institut für Nachrichtentechnik
   X     No Word docs in email	                  TU Darmstadt
 / \  Respect for open standards              Ruf +49-6151-16-3281