On 2023-12-06 at 07:20 -0500, Greg Wooledge wrote:
> On Wed, Dec 06, 2023 at 05:28:19PM +0800, wang yuhang via Bug reports for the
> GNU Bourne Again SHell wrote:
> > When the for loop reaches env, the values of each env are:
> >
> [...]
> > (gdb) p env[16]
> > $21 = 0x7ffce3c2e25a "DIRNAME_AL
On 12/11/23 6:20 AM, wang yuhang wrote:
Is this at the same point as the core dump in your previous message?
yes
OK, then I would recommend building an asan-enabled version of bash and
seeing what it tells you.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
`
> Is this at the same point as the core dump in your previous message?
yes
On 12/6/23 4:28 AM, wang yuhang wrote:
> The initialize_shell_variables function is processing env. When the for
loop
> reaches env[16], glibc needs to use the main_arena.top variable.
However, the
> value in the address pointed to by the top variable is overwritten by
env[15],
> causing a
On 12/6/23 3:47 AM, wang yuhang wrote:
The initialize_shell_variables function is processing env. When the for
loop reaches env[16], glibc needs to use the main_arena.top variable.
However, the value in the address pointed to by the top variable is
overwritten by env[15], causing a glibc excep
On Wed, Dec 06, 2023 at 05:28:19PM +0800, wang yuhang via Bug reports for the
GNU Bourne Again SHell wrote:
> When the for loop reaches env, the values of each env are:
>
[...]
> (gdb) p env[16]
> $21 = 0x7ffce3c2e25a "DIRNAME_ALIAS"
> (gdb) p env[17]
> $22 = 0x7ffce3c2e279 "PID="
The missi
> The initialize_shell_variables function is processing env. When the for
loop
> reaches env[16], glibc needs to use the main_arena.top variable. However,
the
> value in the address pointed to by the top variable is overwritten by
env[15],
> causing a glibc exception and resulting in a cor
> Hi. This appears to happen when creating a shell variable from the initial
> environment. I can't reproduce it. If you can find a way to reliably
> reproduce it, please let me know and we can work on it.
So far, we have encountered this issue three times in our environment. The
following is one
> Hi. This appears to happen when creating a shell variable from the initial
> environment. I can't reproduce it. If you can find a way to reliably
> reproduce it, please let me know and we can work on it.
I'm sorry, the environment is quite complex and I couldn't find a way to
reliably reproduc
On 12/4/23 9:38 AM, wang yuhang via Bug reports for the GNU Bourne Again
SHell wrote:
A bash coredump has appeared in my environment, the stack information displayed
by GDB is as follows:
[...]
the problematic bash version is 5.1.8
Hi. This appears to happen when creating a shell v
10 matches
Mail list logo
