The Perl module IO::Pty no longer works after upgrading to 6.4-PRERELEASE. The machine is following RELENG6 using cvsup and was running 6.3 before. IO::Pty (or rather the Perl module Expect) was running fine until the recent upgrade. IO::Pty is included in the distribution of IO::Tty and is used by the Perl module Expect. Re-installing IO::Tty from ports or from CPAN did not help. This also happened on another machine which I upgraded to 6.4-PRERELEASE today in order to verify the problem. Fix: No workaround found yet. How-To-Repeat: install from ports devel/p5-IO-Tty and perform this script $ perl -e 'use IO::Pty; $x= new IO::Pty;' Cannot create a new IO::Tty from fd 4: Bad file descriptor at -e line 1
Responsible Changed From-To: freebsd-bugs->erwin Make this a ports PR and assign.
In the meantime, I found a workaround to avoid the current version of unlockpt() which now calls revoke() which in turn may be the reason for the misbehaving IO::Tty module. See [1] for the commit message describing the modification of unlockpt() and an excerpt of the typescript which shows how to install a modified version of this package. In order to obtain a working lang/p5-Except it is also necessary to install IO::Stty via CPAN. My broken application is now working again, so this problem is no longer serious. Links [1] http://docs.freebsd.org/cgi/mid.cgi?200808200943.m7K9hscU044994 GG
Sorry, I supplied a link for the wrong commit message. However, the change to grantpt.c that I suspect to have broken IO::Pty is documented here: http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/Attic/grantpt.c.diff?r1=1.4.2.3;r2=1.4.2.4 GG
Hello all, Mike Silbersack just asked me to take a look at this problem and I just figured out what it is. The code is obviously wrong, because it calls openpty() to allocate a PTY and open the slave TTY, but it calls unlockpt() afterwards, which is bad. Simple fix: disable HAVE_UNLOCKPT and HAVE_GRANTPT. They should not be called when you use openpty(). Best fix: teach p5-IO-Tty to use posix_openpt(). Which is what I did. What about this patch? Make sure to contact the author of this perl module to get it integrated! %%% --- Makefile.PL +++ Makefile.PL @@ -95,16 +95,17 @@ # checking for various functions -my %funcs = (ttyname => "", - openpty => "-lutil", - _getpty => "", - strlcpy => "", - sigaction => "", - grantpt => "", - unlockpt => "", - getpt => "", - ptsname => "", - ptsname_r => "", +my %funcs = (ttyname => "", + openpty => "-lutil", + _getpty => "", + strlcpy => "", + sigaction => "", + grantpt => "", + unlockpt => "", + getpt => "", + posix_openpt => "", + ptsname => "", + ptsname_r => "", ); foreach my $f (sort keys %funcs) { @@ -290,7 +291,7 @@ msg => "WARNING! Neither ptsname() nor ptsname_r() could be found,\n so we cannot use a high-level interface like openpty().\n", }, { - defines => [qw"-DHAVE_DEV_PTMX -DHAVE_DEV_PTYM_CLONE -DHAVE_DEV_PTC -DHAVE_DEV_PTMX_BSD -DHAVE__GETPTY -DHAVE_OPENPTY -DHAVE_GETPT"], + defines => [qw"-DHAVE_DEV_PTMX -DHAVE_DEV_PTYM_CLONE -DHAVE_DEV_PTC -DHAVE_DEV_PTMX_BSD -DHAVE__GETPTY -DHAVE_OPENPTY -DHAVE_GETPT -DHAVE_POSIX_OPENPT"], msg => "No high-level lib or clone device has been found, we will use BSD-style ptys.\n", }, ) { --- Tty.xs +++ Tty.xs @@ -453,6 +453,18 @@ #if defined(HAVE_PTSNAME) || defined(HAVE_PTSNAME_R) /* we don't need to try these if we don't have a way to get the pty names */ +#if defined(HAVE_POSIX_OPENPT) +#if PTY_DEBUG + if (print_debug) + fprintf(stderr, "trying getpt()...\n"); +#endif + *ptyfd = posix_openpt(O_RDWR|O_NOCTTY); + if (*ptyfd >= 0 && open_slave(ptyfd, ttyfd, namebuf, namebuflen)) + break; /* got one */ + if (PL_dowarn) + warn("pty_allocate(nonfatal): posix_openpt(): %.100s", strerror(errno)); +#endif /* defined(HAVE_POSIX_OPENPT) */ + #if defined(HAVE_GETPT) /* glibc defines this */ #if PTY_DEBUG %%% -- Ed Schouten <ed@80386.nl> WWW: http://80386.nl/
Small cosmetic bug in the patch: * Ed Schouten <ed@80386.nl> wrote: > + fprintf(stderr, "trying getpt()...\n"); This should read: > + fprintf(stderr, "trying posix_openpt()...\n"); -- Ed Schouten <ed@80386.nl> WWW: http://80386.nl/
* Ed Schouten <ed@80386.nl> wrote: > What about this patch? Make sure to contact the author of this perl > module to get it integrated! Never mind. I took care of it. The patch has been integrated and the maintainer will release a new version. -- Ed Schouten <ed@80386.nl> WWW: http://80386.nl/
Responsible Changed From-To: erwin->perl Reassign.
* Ed Schouten <ed@80386.nl> wrote: > * Ed Schouten <ed@80386.nl> wrote: > > What about this patch? Make sure to contact the author of this perl > > module to get it integrated! > > Never mind. I took care of it. The patch has been integrated and the > maintainer will release a new version. Seems the maintainer is taking a longer time than I had expected. Shall I just commit the patch? Still better than leaving the package broken. -- Ed Schouten <ed@80386.nl> WWW: http://80386.nl/
State Changed From-To: open->closed I've committed the patch in the port. It can be removed once a new version is released. Thanks Gerhard for the report and Ed for creating the fix.
erwin 2009-02-02 19:24:49 UTC FreeBSD ports repository Modified files: devel/p5-IO-Tty Makefile Added files: devel/p5-IO-Tty/files patch-Makefile.PL patch-Tty.xs Log: Use posix_openpt() instead of calling openpty() to allocate a PTY and open the slave TTY, and calling unlockpt() afterwards. PR: 128941 Submitted by: ed Reported by: Gerhard Gonter <g.gonter@ieee.org> Revision Changes Path 1.20 +1 -0 ports/devel/p5-IO-Tty/Makefile 1.1 +39 -0 ports/devel/p5-IO-Tty/files/patch-Makefile.PL (new) 1.1 +21 -0 ports/devel/p5-IO-Tty/files/patch-Tty.xs (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"