[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
getpt() weirdness?
From: |
Gergely Nagy |
Subject: |
getpt() weirdness? |
Date: |
Fri, 7 Sep 2001 03:51:59 +0200 |
User-agent: |
Mutt/1.2.5i |
Greetings!
Recently I've been fiddling with aterm, and noticed that it can't
be opened more than ~15-16 times. Therefore, I decided to look at
the problem a bit.
aterm uses getpt() to get a pty, which is good, as far as I know,
and it works fine on Linux (ie, I can open more than 20 aterms).
So, I had a look at this getpt beast..
In sysdeps/unix/sysv/linux/getpt.c, I see the following: if there
is a /dev/ptmx, getpt will use that, if not, then it will fall
back to bsd_getpty.
In sysdeps/unix/bsd/getpt.c, the bsd-style getpt will try to open
/dev/pty[pqrsPQRS][0-9a-v], IF PTYNAME1 and PTYNAME2 is not defined
yet. However, the linux getpt defines them as [p-za-e] and [0-9a-f]
respectively.
On the Hurd, /sbin/MAKEDEV knows about how to create [p-zP-T][0-9a-f].
So, what happens when /dev/ptyp[0-f] is already allocated and one tries
to allocate another one?
I believe that the linux getpt is not compiled on the Hurd (because in
that case, we would have an other problem :), so only the bsd_getpt
will be called, which means that it will try to open /dev/ptypg,
which does not exist! And if it does not, open returns ENOENT,
and that means that getpt will return with -1, although we might have
free ptys around (ptyq* for example).
Since I'm not a glibc guru, and I didn't check that sysv/linux/getpt.c
is really missing from the Hurd compile or not, I may be wrong.
However, the problem is there, and I'm pretty sure the bug lies in getpt.
Cheers,
--
Gergely Nagy \ mhp/|8]
- getpt() weirdness?,
Gergely Nagy <=