Failure to open pty followed by panic

[bogmihdav]

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

[bjorn3]

chown("/dev/pts/2", 62277248, 5) = -1 EPERM (Operation not permitted)

What is the output of tty and ls -l /dev/pts/2?

[bogmihdav]

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.

[bogmihdav]

It also fails to find /dev/pts/2, btw.

[ftilde]

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?