bash does not read startup scripts on some machines

[Justin]

Hello,

I am using a command line ssh tool called qtssh on windows to connect to 
a redhat server.  qtssh is a command line ssh tool built upon putty that 
is included with the visualization toolkit VisIt.  This tool is designed 
to run commands remotely and does not create an interactive shell.  When 
connecting to the redhat server none of my startup scripts appear to be 
executed (.bashrc, .bash_profile, .profile, etc).  However, if I connect 
to my Debian server the .bashrc file is sourced just fine.  From what I 
can tell ssh is starting a non-interactive and non-login shell.  The 
documentation on what is executed when this type of shell is encountered 
says:  'When  bash  is  started  non-interactively,  to run a shell 
script, for example, it looks for the variable BASH_ENV in the 
environment, expands its value if it appears there, and uses the 
expanded value as the name of a file to read and execute.'  This 
variable is not set on any of the machines i'm on and it is not clear 
how to appropriately set this variable.  Am I correct in assuming that 
this variable needs to be set in order to get the dot files sourced and 
if so where is this variable set?


Thanks,
Justin

Re: bash does not read startup scripts on some machines

[Justin]

Thank you for your detailed response.  I worked with the system 
administrators to get this resolved.  In the end they changed pam so 
that it would source .bashrc. 


The added this to /etc/pam.d/sshd:
sessionoptional pam_env.so conffile=/etc/ssh/env.conf 
envfile=/etc/ssh/environment
They left /etc/ssh/env.conf file is left empty (the docs said it is 
required to have a file if this option is used even though in this setup 
it is left empty)


And then they edited /etc/ssh/environment to contain the following:
BASH_ENV=~/.bashrc

This may not be an ideal solution but it works.  Unfortunately I don't 
have control over the commands being ran over ssh as they are being 
generated and executed by a 3rd party application (VisIt). 


Thanks,
Justin

Bob Proulx wrote:

Justin wrote:
  

I am using a command line ssh tool called qtssh on windows to
connect to a redhat server.  qtssh is a command line ssh tool built
upon putty that is included with the visualization toolkit VisIt.
This tool is designed to run commands remotely and does not create
an interactive shell.



You describe an environment that is designed to run scripts only.
Okay.  Seems reasonable to me.

  

When connecting to the redhat server none of my startup scripts
appear to be executed (.bashrc, .bash_profile, .profile, etc).



Not for a non-interactive environment.

  

However, if I connect to my Debian server the .bashrc file is
sourced just fine.



Please see /usr/share/doc/bash/README.Debian.gz for a description of
Debian specific modifications.
  - try to check whether bash is being run by sshd and source
  the .bashrc if so (like the rshd behavior).
Because this is a Debian specific patch it won't exist elsewhere.

  

From what I can tell ssh is starting a non-interactive and non-login
shell.  The documentation on what is executed when this type of
shell is encountered says: 'When bash is started non-interactively,
to run a shell script, for example, it looks for the variable
BASH_ENV in the environment, expands its value if it appears there,
and uses the expanded value as the name of a file to read and
execute.'  This variable is not set on any of the machines i'm on
and it is not clear how to appropriately set this variable.



In traditional ksh there isn't a default $HOME/.kshrc file sourced by
the shell for interacive login shells.  In order to enable this
csh-like feature one needed to set ENV=$HOME/.kshrc (or other name).
However that had the unfortunate effect that scripts also sourced that
same file.  Aliases and functions meant for interactive use could
break scripts not expecting non-standard behavior.  Therefore
typically a somewhat complicated computation such that interactive
shells would source the .kshrc while non-interactive shells would not
source this file.  This was needed for ksh scripts to operate robustly.
  export ENV='${START[(_$-=1)+(_=0)-(_$-!=_${-%%*i*})]}'
  export START=$HOME//.kshrc
Or from the KornShell book.  Requires ksh88 or later.
  export ENV='${FILE[(_$-=0)+(_=1)-_${-%%*I*}]}'
  export FILE=$HOME//.kshrc

Bash avoided these issues by implementing a different set of startup
rules that automatically did the right thing in more cases.  Bash
supports the functionality of the ksh ENV by using a BASH_ENV variable
with similar behavior.  Bash also supports ENV when invoked as 'sh'
and so forth as documented in the manual for legacy support.

Even though bash works as desired most of the time there is still
debate as to what behavior is desired in the subtle differences
between an interactive shell and a non-interactive shell and in a
login shell versus a non-login shell and when being run over a remote
shell connection (e.g. using ssh or rsh) versus not.  Automatically
trying to dynamically choose behavior invariably fails to work in all
cases and causes problems in those failing cases.  This has led to a
rather complex set of rules for shell startup and the files it
sources.  This is the problem you are looking at right now.

My personal opinion is that flexibility is good, if confusing, and I
would rather have it than not.  But keep the rules constant!  When the
rules have changed in the past from one behavior to another it has
caused me grief.  It creates "versionitis" problems trying to adapt to
which shell does what behavior in which version.

There has been various extended mailing list discussions about the
best behavior when being run on a remote shell such as over ssh and
rsh.  Search the archives for a full history.  Some want it and some
don't want it.

  

Am I correct in assuming that this variable needs to be set in order
to get the dot files sourced and if so where is this variable set?



Well, yes and no.  If it is set, such as in a user's .profile then
bash will source the indicated file.  However IMNHO this is only
desirable to directly support this ksh-like behavior.  Most 

Bash messes up spaces in command line agruments.

[Herrmann, Justin]

Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib
-g -02 -Wall
uname output: Linux justin-desktop 2.6.22-14-generic #1 SMP Tue Feb 12
07:42:25 UTC 2008 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu

Bash Version: 3.2
Patch Level: 25
Release Status: release

Description: When I try to pass strings inside double or single quotes
as command line arguments to my Bash script, leading spaces, trailing
spaces, and multiple grouped embedded spaces are removed from the
string.  This also prevents me from passing in only a space or spaces as
arguments to my script.

Repeat-By: Save this script as 'startup':

#!/bin/bash
echo $#
for ((index = 0; index <= $#; index++))
do
echo "$index |$(eval echo \${$index})|"
done
exit 0

then type: ./startup ' some   words  '

the script will print out:
1
0 |./startup|
1 |some words|

Re: time hangs or seg faults

[Justin Williams]

Sorry about that; this is on a gentoo system, hardened kernel 2.6.23,
installed with normal ebuild procedures, which pulls the authors tarball ,
extracts it, applies patches and builds.

On Thu, Jul 23, 2009 at 8:49 AM, Greg Wooledge  wrote:

> On Wed, Jul 22, 2009 at 09:19:22PM +, rjustinwilli...@gmail.com wrote:
> > On one system, I have installed bash from one version to the next, from
> > 3.2.17 to 4.0.10. With each version, the built-in "time" command hangs.
>
> Probably some problem with the build.  Since you didn't even say what
> operating system you're on, or whether you compiled it yourself or used
> a prebuilt binary, it's going to be hard for anyone to help you.
>
> I would suggest posting to the list again with all the relevant details:
>
>  * Operating system name and version
>  * Prebuilt binary or self-compiled
>  * If prebuilt binary: where it came from
>  * If self-compiled: compiler name and version, and what settings you used
>  * What command you type to produce the problem
>
> That's a minimal starting point.  Once the basic details are clear, people
> may need additional information.
>

Re: time seg fault

[Justin Williams]

Unfortunately, if I try to strace it (strace time ls), I get command not
found.
If I try to strace `time ls`, I get a hung screen.

Attaching gdb to the running bash session from which I am trying to run
time, I don't get any useful pointers, but, what I get is below:

(no debugging symbols found)
Attaching to program: /bin/bash, process 5647
linux-nat.c:988: internal-error: linux_nat_attach: Assertion `pid == GET_PID
(inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP'
failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

I also, for grins, tried sleep 5 && time ls in the bash session and, while
it was sleeping, attached the gdb to the bash session, to see if I could get
anything that way, and got the below:
warning: no loadable sections found in added symbol-file system-supplied DSO
at 0x7b122651f000
(no debugging symbols found)
0x35c7a95e7884 in ?? ()

Not sure if this helps get any closer, but, thanks!

On Thu, Jul 23, 2009 at 8:29 AM, Chet Ramey  wrote:

> rjustinwilli...@gmail.com wrote:
> > time echo "bah"
> > time ls
> > time who
> >
> > Running the commands without the time, they return results as close to
> > instantly as I can think of, but, try to time them, in bash, and they
> > all hang.
>
> Since nobody seems to be able to reproduce this, maybe attaching to the
> hanging bash process with gdb and doing a stack traceback will provide
> better information.
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>
> Chet Ramey, ITS, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/ 
>

Re: time seg fault

[Justin Williams]

"/bin/bash", {st_mode=S_IFREG|0755, st_size=1052984, ...}) = 0
open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 3
read(3, "65536\n", 31)  = 6
close(3)= 0
mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x3061588ea000
getgroups(65536, [10, 452, 1006])   = 3
stat("/bin/bash", {st_mode=S_IFREG|0755, st_size=1052984, ...}) = 0
getpgrp()   = 12193
rt_sigaction(SIGCHLD, {0x74c0771a74a, [], SA_RESTORER, 0x3061585d0f10},
{SIG_DFL}, 8) = 0
getrlimit(RLIMIT_NPROC, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) =
0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++


On Thu, Jul 23, 2009 at 10:12 AM, Greg Wooledge  wrote:

> On Thu, Jul 23, 2009 at 09:59:48AM -0400, Justin Williams wrote:
> > Unfortunately, if I try to strace it (strace time ls), I get command not
> > found.
>
> ''strace time ls'' will try to run the external command ''time'' which
> apparently you haven't got installed.  (Which is probably good in this
> case, as it avoided some confusion)
>
> What you want is:
>
>  strace bash -c 'time ls'
>
> (You may need to give additional options to strace as well, to get the
> behavior you want.)
>
> > If I try to strace `time ls`, I get a hung screen.
> >
> > Attaching gdb to the running bash session from which I am trying to run
> > time, I don't get any useful pointers, but, what I get is below:
> >
> > (no debugging symbols found)
> > Attaching to program: /bin/bash, process 5647
> > linux-nat.c:988: internal-error: linux_nat_attach: Assertion `pid ==
> GET_PID
> > (inferior_ptid) && WIFSTOPPED (status) && WSTOPSIG (status) == SIGSTOP'
> > failed.
> > A problem internal to GDB has been detected,
> > further debugging may prove unreliable.
>
> Maybe your libc is broken?  Or your compiler, if all of these are
> self-compiled gentoo e-builds?
>

Re: time seg fault

[Justin Williams]

Greg, you mentioned that it might be a build bug causing headaches.
As the same build environment was used to build tcsh, and to
(re)build/upgrade bash on this system, and tcsh's time works while bash's
doesn, I'm curious where the idea comes from.  I don't doubt it, but I'm
curious what leads you to that.

Thanks!
Justin

On Thu, Jul 23, 2009 at 10:24 AM, Justin Williams  wrote:

> That's a huge help; thanks!
>
> Output below:
> execve("/bin/bash", ["bash", "-c", "time ls"], [/* 22 vars */]) = 0
> brk(0)   = 0x74c079d3c20
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x306158131000
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY)  = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=18395, ...}) = 0
> mmap(NULL, 18395, PROT_READ, MAP_PRIVATE, 3, 0) = 0x306158132000
> close(3)= 0
> open("/lib/libncurses.so.5", O_RDONLY)  = 3
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\r\2\0\0\0\0\0"..., 832)
> = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=406112, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x306158137000
> mmap(NULL, 2504632, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0x306158138000
> mprotect(0x30615818d000, 2093056, PROT_NONE) = 0
> mmap(0x30615838c000, 61440, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x54000) = 0x30615838c000
> mmap(0x30615839b000, 1976, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x30615839b000
> close(3)= 0
> open("/lib/libdl.so.2", O_RDONLY)   = 3
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\16\0\0\0\0\0\0"..., 832)
> = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=14328, ...}) = 0
> mmap(NULL, 2109600, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0x30615839c000
> mprotect(0x30615839e000, 2097152, PROT_NONE) = 0
> mmap(0x30615859e000, 8192, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x30615859e000
> close(3)= 0
> open("/lib/libc.so.6", O_RDONLY)= 3
> read(3,
> "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\360\342\1\0\0\0\0\0"...,
> 832) = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=1330184, ...}) = 0
> mmap(NULL, 3438296, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
> 0x3061585a
> mprotect(0x3061586de000, 2097152, PROT_NONE) = 0
> mmap(0x3061588de000, 20480, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e000) = 0x3061588de000
> mmap(0x3061588e3000, 18136, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3061588e3000
> close(3)= 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x3061588e8000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x3061588e9000
> arch_prctl(ARCH_SET_FS, 0x3061588e8e60) = 0
> open("/dev/urandom", O_RDONLY)  = 3
> read(3, "\323k\263\254\265\6\201\247", 8) = 8
> close(3)= 0
> mprotect(0x3061588de000, 16384, PROT_READ) = 0
> mprotect(0x30615859e000, 4096, PROT_READ) = 0
> mprotect(0x30615838c000, 57344, PROT_READ) = 0
> mprotect(0x74c079ba000, 16384, PROT_READ) = 0
> mprotect(0x30615812f000, 4096, PROT_READ) = 0
> munmap(0x306158132000, 18395)   = 0
> rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
> open("/dev/tty", O_RDWR|O_NONBLOCK) = 3
> close(3)= 0
> brk(0)  = 0x74c079d3c20
> brk(0x74c079f4c20)  = 0x74c079f4c20
> brk(0x74c079f5000)  = 0x74c079f5000
> getuid()= 1005
> getgid()= 1006
> geteuid()   = 1005
> getegid()   = 1006
> rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
> open("/proc/meminfo", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x306158132000
> read(3, "MemTotal: 18529272 kB\nMemFre"..., 1024) = 725
> close(3)= 0
> munmap(0x306158132000, 4096)= 0
> rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGINT, {SIG_DFL

bash completion crash

[Justin Pryzby]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' 
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic
uname output: Linux appserver 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Jan 4 
17:31:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 4.1
Patch Level: 2
Release Status: release

Description:
SIGABRT during readline completion.

Repeat-By:
Unable to reproduce

I couldn't see that this had been reported/fixed
..but did find this:
https://lists.nongnu.org/archive/html/bug-bash/2017-06/msg00267.html

[pryzbyj@appserver ~]$ rpm -q bash
bash-4.1.2-48.el6.x86_64

[pryzbyj@appserver ~]$ cat /etc/*release
CentOS release 6.9 (Final)

Program terminated with signal 6, Aborted.
#0  0x0033fbe32495 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install 
glibc-2.12-1.209.el6_9.2.x86_64 libgcc-4.4.7-18.el6.x86_64 
ncurses-libs-5.7-4.20090207.el6.x86_64
(gdb) bt
#0  0x0033fbe32495 in raise () from /lib64/libc.so.6
#1  0x0033fbe33bfd in abort () from /lib64/libc.so.6
#2  0x0033fbe703a7 in __libc_message () from /lib64/libc.so.6
#3  0x0033fbe75dee in malloc_printerr () from /lib64/libc.so.6
#4  0x0033fbe78f66 in _int_free () from /lib64/libc.so.6
#5  0x0045c34d in command_word_completion_function (hint_text=0x1cdb290 
"sup", state=0) at bashline.c:1598
#6  0x0048b4b9 in rl_completion_matches (text=0x1cdb290 "sup", 
entry_function=0x45c050 ) at complete.c:1924
#7  0x0045cc36 in bash_default_completion (text=0x1cdb290 "sup", 
start=0, end=, qc=, compflags=) at bashline.c:1425
#8  0x0045df6c in attempt_shell_completion (text=0x1cdb290 "sup", 
start=0, end=3) at bashline.c:1374
#9  0x0048b55f in gen_completion_matches (text=0x1cdb290 "sup", 
start=, end=, our_func=0x48a120 
, found_quote=,
quote_char=) at complete.c:1040
#10 0x0048c9f8 in rl_complete_internal (what_to_do=9) at complete.c:1783
#11 0x00484c55 in _rl_dispatch_subseq (key=9, map=0x6d7ba0, 
got_subseq=0) at readline.c:825
#12 0x00485426 in readline_internal_char () at readline.c:603
#13 0x00485835 in readline_internal_charloop (prompt=) at readline.c:630
#14 readline_internal (prompt=) at readline.c:644
#15 e (prompt=) at readline.c:388
#16 0x0041e8a3 in yy_readline_get () at ./parse.y:1444
#17 0x0041fcae in yy_getc (remove_quoted_newline=1) at ./parse.y:1378
#18 shell_getc (remove_quoted_newline=1) at ./parse.y:2224
#19 0x0042258a in read_token (command=0) at ./parse.y:2892
#20 0x00425347 in yylex () at ./parse.y:2512
#21 yyparse () at y.tab.c:2048
#22 0x0041d48a in parse_command () at eval.c:229
#23 0x0041d556 in read_command () at eval.c:273
#24 0x0041d7a8 in reader_loop () at eval.c:138
#25 0x0041cebc in main (argc=, 
argv=0x7fff69bd1408, env=0x7fff69bd1418) at shell.c:759

Bash segfaults when using extglob on an empty var

[Justin Wood (Callek)]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
uname output: Linux lyra 5.19.14-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed
Oct 5 21:31:17 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.2
Patch Level: 2
Release Status: release

Description:
Bash segfaults when using extglob on an empty var. Regression in 5.2.2
compared to 5.1.16

#0  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:74
#1  0x55cbe3eb4cd5 in pat_subst (string=string@entry=0x55cbe62cf690 "",
pat=0x55cbe62cf821 "*([.])",
rep=rep@entry=0x0, mflags=mflags@entry=65) at
/usr/src/debug/bash-5.2.2-1.fc36.x86_64/subst.c:8960
#2  0x55cbe3eb5737 in parameter_brace_patsub
(varname=varname@entry=0x55cbe6296780
"foo",
value=value@entry=0x55cbe62959b0 "", estatep=estatep@entry=0x7ffeada25340,
patsub=,
patsub@entry=0x55cbe62cf560 "#*([.])", quoted=quoted@entry=0,
pflags=pflags@entry=8, flags=0)
at /usr/src/debug/bash-5.2.2-1.fc36.x86_64/subst.c:9216
#3  0x55cbe3eb6ffa in parameter_brace_expand
(string=string@entry=0x55cbe6295c70
"${foo/#*([.])}",
indexp=indexp@entry=0x7ffeada253f4, quoted=quoted@entry=0,
pflags=pflags@entry=8,
quoted_dollar_atp=quoted_dollar_atp@entry=0x7ffeada254d8,
contains_dollar_at=contains_dollar_at@entry=0x7ffeada254d0)
at /usr/src/debug/bash-5.2.2-1.fc36.x86_64/subst.c:9960
#4  0x55cbe3eb92dd in param_expand (string=string@entry=0x55cbe6295c70
"${foo/#*([.])}",
sindex=sindex@entry=0x7ffeada254dc, quoted=quoted@entry=0,
expanded_something=expanded_something@entry=0x0,
contains_dollar_at=contains_dollar_at@entry=0x7ffeada254d0,
quoted_dollar_at_p=quoted_dollar_at_p@entry=0x7ffeada254d8,
had_quoted_null_p=0x7ffeada254d4, pflags=8)
at /usr/src/debug/bash-5.2.2-1.fc36.x86_64/subst.c:10522

Repeat-By:

shopt -s extglob
foo=
foo=${foo/#*([.])} || echo sad
#  parens required to reproduce, but unnecessary otherwise.