Re: bash encountered a coredump issue with stepping on memory
> 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 of the coredump information #0 __pthread_kill_implementation (threadid=
Re: bash encountered a coredump issue with stepping on memory
> 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 coredump When the for loop reaches env, the values of each env are: (gdb) p env[0] $5 = 0x7ffce3c2e0bc "SHELL=/bin/bash" (gdb) p env[1] $6 = 0x7ffce3c2e0cc "REPO_PATH=/opt/pub/software" (gdb) p env[2] $7 = 0x7ffce3c2e0e8 "CURL_ALIAS=/usr/bin/curl" (gdb) p env[3] $8 = 0x7ffce3c2e101 "FIND_ALIAS=/usr/bin/find" (gdb) p env[4] $9 = 0x7ffce3c2e11a "IPMC_AGENT_ROOT=/opt/oss/manager/agent/DeployAgent" (gdb) p env[5] $10 = 0x7ffce3c2e14d "PGREP_ALIAS=/usr/bin/pgrep" (gdb) p env[6] $11 = 0x7ffce3c2e168 "FSCK_ALIAS=/usr/sbin/fsck.ext4" (gdb) p env[7] $12 = 0x7ffce3c2e187 "enableServiceIdentity=/uds" (gdb) p env[8] $13 = 0x7ffce3c2e1a2 "SUPER_ROOT=/opt/sudobin/" (gdb) p env[9] $14 = 0x7ffce3c2e1bb "HOSTNAME_ALIAS=/bin/hostname" (gdb) p env[10] $15 = 0x7ffce3c2e1d8 "SUDO_GID=2000" (gdb) p env[11] $16 = 0x7ffce3c2e1e6 "HISTCONTROL=" (gdb) p env[12] $17 = 0x7ffce3c2e1f3 "MKFIFO_ALIAS=/usr/bin/mkfifo" (gdb) p env[13] $18 = 0x7ffce3c2e210 "CHOWN_ALIAS=/bin/chown" (gdb) p env[14] $19 = 0x7ffce3c2e227 "BASH_ALIAS=/bin/bash" (gdb) p env[15] $20 = 0x7ffce3c2e23c "PROCESS_NAME=hofsosdfileagent" (gdb) p env[16] $21 = 0x7ffce3c2e25a "DIRNAME_ALIAS" (gdb) p env[17] $22 = 0x7ffce3c2e279 "PID="
Re: bash encountered a coredump issue with stepping on memory
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 missing '=' in DIRNAME_ALIAS appears to be noteworthy. I could imagine a library function scanning through these strings, and for each one, iterating from the start and looking for '='. In the case of DIRNAME_ALIAS, it never finds one, so it marches off past the edge of the allocated memory chunk. This is pure speculation, of course, until someone actually tests it.
