| [hatari-devel] Deadlock while closing serial port |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: [hatari-devel] Deadlock while closing serial port
- From: Christian Zietz <czietz@xxxxxxx>
- Date: Sun, 24 Apr 2022 17:58:19 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1650815900; bh=MO3lhM9PRHqMg8rJN6ZWznp/70QVWiIgcYPUyE7myaQ=; h=X-UI-Sender-Class:Date:To:From:Subject; b=AMS5h+jnb3pbHiK9Zd7BKKaThm3OkhFkP0Bo1rdrXrJV5EwSlAefqfUiauAsTtnup bllfFi/JMGiIcsiHbyGOI/EPnuPlSOESlTsQQLBxZYs4PFgCEB+hY8xuNjeYhzA2iu 8WY+jjVws735SwjVNufwelRr6LqdWHm5reK+AHG4=
Hi,
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
terminates.
I therefore suggest either kill the RS232 thread or use non-blocking
reads to that it can be terminated cleanly before calling fclose().
Regards
Christian