ugdb
ugdb copied to clipboard
ftilde
Failure to open pty followed by panic
Hi, I came across ugdb while looking for a better alternative to gdb's builtin TUI, so I'm grateful that an alternative exists. Unfortunately, I cannot run ugdb, as it panics with the message "Could not create pty.". The log file saved in /tmp is empty, so I'm going to post a bit of an strace instead. Is it possible to implement a fix or workaround? Other TUI programs like vim work well in the same environment.
A quick google search suggested that it might have to do with devpts (most of it went over my head though), so here's the mount as well:
$ mount | grep devpts devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
Strace:
open("/dev/ptmx", O_RDWR) = 4
statfs("/dev/pts", {f_type=DEVPTS_SUPER_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NOEXEC|ST_RELATIME}) = 0
ioctl(4, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(4, TIOCGPTN, [2]) = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
getuid() = 62277248
socket(AF_LOCAL, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 5
connect(5, {sa_family=AF_LOCAL, sun_path="/var/run/nscd/socket"}, 110) = 0
sendto(5, "\2\0\0\0\f\0\0\0\6\0\0\0group\0", 18, MSG_NOSIGNAL, NULL, 0) = 18
poll([{fd=5, events=POLLIN|POLLERR|POLLHUP}], 1, 5000) = 1 ([{fd=5, revents=POLLIN}])
recvmsg(5, {msg_name(0)=NULL, msg_iov(2)=[{"group\0", 6}, {"\310O\3\0\0\0\0\0", 8}], msg_controllen=20, [{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, [6]}], msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 14
mmap(NULL, 217032, PROT_READ, MAP_SHARED, 6, 0) = 0x7fc93c6ef000
close(6) = 0
close(5) = 0
chown("/dev/pts/2", 62277248, 5) = -1 EPERM (Operation not permitted)
write(1, "\33[?1049l\33[?25h\n", 15[?1049l[?25h
) = 15
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "Oh no! ugdb crashed!\n", 21Oh no! ugdb crashed!
) = 21
chown("/dev/pts/2", 62277248, 5) = -1 EPERM (Operation not permitted)
What is the output of tty and ls -l /dev/pts/2?
I opened a new terminal, and the strace showed /dev/pts/1 this time around. Afterwards, for tty, the output is /dev/pts/0 and for the ls -l /dev/pts/1 it fails to find the file.
Hi!
The reason that you can't find the file after ugdb crashes is that the
pty in question is not the one that your terminal emulator
uses/provides, but instead a second pty that is created by ugdb itself
and passed to gdb (and subsequently its child, the debuggee process) so
that we can interact with it in a separate terminal "window"/pane within
ugdb (at the bottom right). As far as I know, the slave part of the tty
(/dev/pts/...) only lives as long as the process that created the master
part, which is ugdb itself. So, when you try to stat /dev/pts/2 (the
path from strace) the file does not exist anymore.
The pty is created here:
https://github.com/ftilde/unsegen_terminal/blob/74c1b2c9367b7f7cbd71f761ff45d450f1efc9d1/src/pty/mod.rs#L174
The call that fails here is probably grantpt since according to its
man page "The user ID of the slave is set to the real UID of the calling
process. The group ID is set to an unspecified value (e.g., tty)."
which sounds like it would match the failed chown call.
To confirm this, maybe you could try to run a short c program with
posix_openpt and grantpt and see if this fails as well.
I'm still not sure why this would fail for you, though. Somewhat related to this I found the following stackoverflow post:
https://stackoverflow.com/questions/31533523/grantpt-report-error-after-unshare
Do you (try to) run ugdb in a container/user namespace?
Another thing to note is that devpts seems to be mounted with different options on my system:
$ mount | grep devpts devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
Maybe this (mode=620 vs mode=600 or the missing gid=5) is the problem?
