> > --- when I run a console program and try to background it with ctl-z, it > > hangs > > (maybe only the first time, not sure) > > repeated ctl-c gets me back to the shell, then the program is in the > > background > > > > riscv32 ~ # python > > Python 3.11.5 (main, Aug 31 2023, 21:56:30) [GCC 13.2.1 20230826] on linux > > Type "help", "copyright", "credits" or "license" for more information. > >>>> > > [1]+ Stopped python > > ^C^C^C^C^C^C^C > > riscv32 ~ # ^C > > riscv32 ~ # > > riscv32 ~ # jobs > > [1]+ Stopped python > > riscv32 ~ # fg > > python > > It would help to see where bash is hanging, if it is -- attach to it with > gdb and run a backtrace. >
So I rebuilt bash with debug info, and network-attached host gdb to the debug facility of qemu-user. gdb only managed to get control when I pressed after ctl-z ctl-c. ==============riscv32 terminal=============================================== riscv32 ~ # riscv32 ~ # python Python 3.11.5 (main, Aug 31 2023, 21:56:30) [GCC 13.2.1 20230826] on linux Type "help", "copyright", "credits" or "license" for more information. >>> [1]+ Stopped python ^C ==============gdb terminal=================================================== [...] ^CThe target is not responding to interrupt requests. Stop debugging it? (y or n) n Program received signal SIGINT, Interrupt. 0x5558783c in waitchld (block=block@entry=0, wpid=-1) at jobs.c:3883 3883 jobs.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt #0 0x5558783c in waitchld (block=block@entry=0, wpid=-1) at jobs.c:3883 #1 0x55587b48 in sigchld_handler (sig=<optimized out>) at jobs.c:3751 #2 <signal handler called> #3 0x2b2d2540 in ?? () (gdb) ==============gdb terminal=================================================== jobs.c: 3878 #if defined (PROCESS_SUBSTITUTION) 3879 /* Only manipulate the list of process substitutions while SIGCHLD 3880 is blocked. We only use this as a hint that we can remove FIFOs 3881 or close file descriptors corresponding to terminated process 3882 substitutions. */ 3883 if ((ind = find_procsub_child (pid)) >= 0) 3884 set_procsub_status (ind, pid, WSTATUS (status)); 3885 #endif > > > --- make, when building something, seems to always start only one job in > > parallel > > That sounds like make's autoconf found something it didn't like. > We found another oddity in make [1,2], where apparently wait() returns an undocumented exit code. Since wait seems to also be involved above, I tend to blame this in qemu now... [1] https://savannah.gnu.org/bugs/?64664 [2] https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg03207.html -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice)
signature.asc
Description: This is a digitally signed message part.
