On Thursday, 3 March 2022 11:00:07 PST Tobias Leupold wrote: > Am Donnerstag, 3. März 2022, 19:06:21 CET schrieb Stefan Brüns: > > Are you using either Qt5 < 5.15 or a kernel version which does not support > > CLONE_FD? - then you are relying on SIGCHLD for process exit notification. > > > > CLONE_FD: https://lwn.net/Articles/636646/ > > Qt5: https://codereview.qt-project.org/c/qt/qtbase/+/108456/ > > > > sane-backends/backend/plustek-usbhw.c messes with the signal handlers and > > fails to restore it: `sigaction(..., ..., NULL)`
If CLONE_PIDFD is active, we don't use the SIGCHLD handler to be notified of process exit, but SIGCHLD must not be ignored with SIG_IGN. That causes the kernel not to notify anything. https://gitlab.com/sane-project/backends/-/blob/master/backend/plustek-usbhw.c I see sigaction, but it is only messing with SIGALRM. Yes, it should restore previous the handler (probably SIG_DFL) after the alarm is done, but this isn't the issue. It also messes with the signal block mask, but I don't see a problem there either: it blocks and unblocks SIGALRM. > I use Qt 5.15.2 and Gentoo's kernel 5.15.16. Is there something I can check > to figure out if this could cause the problem? Apparently, there's no > kernel option I can set? You can strace the process. Add the options -f -bexecve to see the current process and its forks & threads, but stop when it executes a child process. You should see SIGCHLD line, like this: kill(669903, SIGTERM) = 0 poll([{fd=3, events=0}, {fd=5, events=0}, {fd=6, events=POLLIN}, {fd=8, events=POLLIN}, {fd=12, events=POLLIN}], 5, 5000) = 4 ([{fd=5, revents=POLLERR}, {fd=6, revents=POLLHUP}, {fd=8, revents=POLLHUP}, {fd=12, revents=POLLIN}]) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=669903, si_uid=1000, si_status=SIGTERM, si_utime=0, si_stime=0} --- fcntl(12, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK) waitid(P_PIDFD, 12, {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=669903, si_uid=1000, si_status=SIGTERM, si_utime=0, si_stime=0}, WNOHANG|WEXITED, NULL) = 0 fd 12 is the pidfd in this case. Anyway, search for SIGCHLD in the trace and see if anything is setting a handler for it. On kernels >= 5.4, Qt doesn't do it, so if you see any mention of it aside from deliveries like above, it came from elsewhere. > Apart from that, the scanner in question actually does use the plustek > backend! I fear there's no way to fix this in my code?! Fix the problem where the problem is. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
