[Top][All Lists]

[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


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]

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.

Gergely Nagy \ mhp/|8]

reply via email to

[Prev in Thread] Current Thread [Next in Thread]