On Wed, Sep 17, 2025 at 10:29:32AM +0200, Bash development wrote: > Andreas Kähäri wrote: > > Can you say something about the version of Bash you're running and on > > what platform? I can not reproduce the hanging behaviour of "test1" > > using Bash 5.2.37 on Alpine Linux, nor with 5.2.15 on Debian, or with > > 5.3.0 buildt from the latest sources on Alpine. > > Now that you say this, I realize that I simplified the examples too much. > I am reproducing the problem with both bash-5.2.37 on Alpine, > and with bash-5.3.3 on Slackware. > The CORRECT examples should be: > > cat <<'EOF' >./test0 > #!/bin/bash > [ -t 0 ] && [ -t 1 ] || exit > echo " ==> NOTE: RUNNING." > read -d "" -t 0 > echo " ==> NOTE: RETURNING: \$? $?" > EOF > > cat <<'EOF' >./test1 > #!/bin/bash > [ -t 0 ] && [ -t 1 ] || exit > echo " ==> NOTE: RUNNING." > read -d "" -t 1 > echo " ==> NOTE: RETURNING: \$? $?" > EOF > > chmod +x ./test0 ./test1 > ./test0 & wait > ./test1 & wait > > RESULTS: > ./test0 finishes execution. > ./test1 gets stuck after echo "RUNNING", and before echo "RETURNING". > > EXPECTED RESULT: Given a timeout option, the read commanad should return > (possibly sooner but no later than) after the timeout expires. > > Alternatively, if "-t 1" is going to have some such problems (and if > we decide to call that "normal"), then "-t 0" should be able to > detect such a condition and return with some *meaningful* return code. > > Alternatively (#2), the [ -t N ] tests should be able to help us avoid it. > > Alternatively (#3), there must be some other way to detect such condition, > and avoid getting stuck, without shelling out to external commands. > > Pourko > > --- > [*] As you see, I am not even mentioning my grievances about the "-t 0" > option for not running its test in raw term mode (for historical reasons > I guess), or for not having some other option that could do a non-blocking > read on the raw term input buffer without the need of timeout. > > I tried this with 5.3.3(1)-release[a8a1c2fa] under Slackware. test1 gave:
==> NOTE: RUNNING. [1]+ Stopped ./test1 -bash: wait: warning: job 1[4286] stopped Do you by any chance have job control disabled? But, things get interesting when I kill the job:- $ kill %1 [1]+ Stopped ./test1 ./test1: line 4: read: error setting terminal attributes: Interrupted system call malloc: unknown:0: assertion botched free: underflow detected; magic8 corrupted Aborting...$ [1]+ Aborted (core dumped) ./test1 By now, I had installed a rebuilt bash with debug enabled and re-run test1. We can disregard the warning about core maybe not matching:- $ gdb $(type -p bash) GNU gdb (GDB) 11.2 Copyright (C) 2022 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-slackware-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/bash... (gdb) core core warning: core file may not match specified executable file. [New LWP 17339] Core was generated by `/bin/bash ./test1'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f3142a93868 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007f3142a93868 in raise () from /lib64/libc.so.6 #1 0x00007f3142a7a5f2 in abort () from /lib64/libc.so.6 #2 0x000000000045eff2 in programming_error ( format=0x54e2a0 "free: underflow detected; magic8 corrupted") at ../error.c:162 #3 0x000000000052ea4e in xbotch (mem=0x353ca710, e=4, s=0x54e2a0 "free: underflow detected; magic8 corrupted", file=0x0, line=0) at ../../../lib/malloc/malloc.c:382 #4 0x000000000052f9fc in internal_free (mem=0x353ca710, file=0x0, line=0, flags=0) at ../../../lib/malloc/malloc.c:987 #5 0x00000000005308cd in free (mem=0x353ca710) at ../../../lib/malloc/malloc.c:1458 #6 0x00000000004bca8b in xfree (string=0x353ca710) at ../xmalloc.c:153 #7 0x0000000000494df7 in unwind_frame_run_internal (tag=0x54913d "read_builtin") at ../unwind_prot.c:286 #8 0x00000000004945a3 in run_unwind_frame (tag=0x54913d "read_builtin") at ../unwind_prot.c:122 #9 0x00000000004cfae3 in read_builtin (list=0x0) at ../../builtins/../../builtins/read.def:550 #10 0x000000000044fd20 in execute_builtin (builtin=0x4cf043 <read_builtin>, words=0x353c6fd0, flags=0, subshell=0) at ../execute_cmd.c:5097 #11 0x0000000000450f17 in execute_builtin_or_function (words=0x353c6fd0, builtin=0x4cf043 <read_builtin>, var=0x0, redirects=0x0, fds_to_close=0x353c6ad0, flags=0) at ../execute_cmd.c:5643 #12 0x000000000044f49f in execute_simple_command (simple_command=0x353c69d0, pipe_in=-1, pipe_out=-1, async=0, fds_to_close=0x353c6ad0) at ../execute_cmd.c:4856 #13 0x0000000000447496 in execute_command_internal (command=0x353c6a90, asynchronous=0, pipe_in=-1, pipe_out=-1, fds_to_close=0x353c6ad0) at ../execute_cmd.c:938 #14 0x00000000004465f3 in execute_command (command=0x353c6a90) at ../execute_cmd.c:456 #15 0x000000000042c8ea in reader_loop () at ../eval.c:183 #16 0x0000000000429cc9 in main (argc=2, argv=0x7ffdec6f59d8, env=0x7ffdec6f59f0) at ../shell.c:834 Maybe there is a bug in here somewhere after all. Cheers ... Duncan.
