[hatari-devel] Deadlock while closing serial port

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


today, I encountered a deadlock while running Hatari attached to a
(real) serial port. This is on Linux, Debian 10, on a Raspberry Pi 400.

Consider Hatari running like so:
hatari --rs232-in /dev/ttyUSB0 --rs232-out /dev/ttyUSB0

When I quit Hatari (e.g. by AltGr+Q) it hangs until killed by SIGKILL.
Attaching gdb gives away the reason. One thread is spinning to acquire a
lock while trying to call fclose() on the input handle:

#0  __lll_lock_wait_private (futex=0x2be1278) at ./lowlevellock.c:33
#1  0xf7a5328c in __GI__IO_un_link (fp=0x2be11d8) at genops.c:61
#2  0xf7a532ec in __GI__IO_un_link (fp=<optimized out>) at genops.c:54
#3  0xf7a43d08 in _IO_new_fclose (fp=0x2be11d8) at iofclose.c:49
#4  0x001c2a58 in RS232_CloseCOMPort ()
    at /home/pi/devel/hatari/src/rs232.c:243
#5  0x001c2c08 in RS232_UnInit () at /home/pi/devel/hatari/src/rs232.c:379
#6  0x00182394 in Main_UnInit () at /home/pi/devel/hatari/src/main.c:792
#7  main (argc=<optimized out>, argv=<optimized out>)
    at /home/pi/devel/hatari/src/main.c:975

Meanwhile Hatari's separate RS232 thread is blocking to read from the
same input handle (but the attached device is not sending any data):

(gdb) thread 10
[Switching to thread 10 (Thread 0xeceff380 (LWP 8146))]
#0  __GI___libc_read (nbytes=1, buf=0x2be121f, fd=8)
    at ../sysdeps/unix/sysv/linux/read.c:26
26	../sysdeps/unix/sysv/linux/read.c: No such file or directory.
(gdb) bt
#0  __GI___libc_read (nbytes=1, buf=0x2be121f, fd=8)
    at ../sysdeps/unix/sysv/linux/read.c:26
#1  __GI___libc_read (fd=8, buf=0x2be121f, nbytes=1)
    at ../sysdeps/unix/sysv/linux/read.c:24
#2  0xf7a52abc in _IO_new_file_underflow (fp=0x2be11d8) at libioP.h:839
#3  0xf7a53c68 in __GI__IO_default_uflow (fp=0x2be11d8) at libioP.h:839
#4  0xf7a4d744 in _IO_getc (fp=0x2be11d8) at libioP.h:759
#5  0x001c2a94 in RS232_ThreadFunc (pData=<optimized out>)
    at /home/pi/devel/hatari/src/rs232.c:288

At least with the C library used on my system fclose() blocks until any
pending reads return. As a proof: If I force the device on the serial
port to transmit some characters, the deadlock is broken and Hatari

I therefore suggest either kill the RS232 thread or use non-blocking
reads to that it can be terminated cleanly before calling fclose().


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/