Re: That BASH crash, revisited

Gordon.Schumacher@xxxxxxxxxxx wrote:
I've now been working with this stuff enough - and my new
job has afforded me the time - that I've been able to
reproduce it in a very short script.

It appears to require the use of command substitution -
of any kind - from within a function:

#!/bin/sh

func()
{
echo Calling out to the world...
echo `uname`
echo Preparing to meet our maker!
return
}

func


This line will also make it crash:
boom=$(uname)

While the first do crash for me, the second one doesn't.

You fail to tell us which OS you're using.

My tests were made on WINDOWS 98 SE.


Here's the crashdump, as run through my variant of bfdsymify:

Exiting due to signal SIGSEGV
General Protection Fault at eip=00025f4a
eax=cfcfcfcf ebx=00139d48 ecx=0000000c edx=cfcfcfcf esi=00038ed7
edi=00038ed7
ebp=0012c9d8 esp=0012c9c0 program=c:\djgpp\bin\bash.exe
cs: sel=01ff base=02b70000 limit=0014ffff
ds: sel=0207 base=02b70000 limit=0014ffff
es: sel=0207 base=02b70000 limit=0014ffff
fs: sel=01d7 base=0000de50 limit=0000ffff
gs: sel=0217 base=00000000 limit=0010ffff
ss: sel=0207 base=02b70000 limit=0014ffff
App stack: [0012d668..000ad668] Exceptn stack: [000accac..000aad6c]

Call frame traceback EIPs:
0x00025f4a hash_search
c:/djgpp/src/bash-2.05b/djbuild/../hashlib.c:175
0x000154af kill_all_local_variables
c:/djgpp/src/bash-2.05b/djbuild/../variables.c:1347
0x00015516 var_lookup
c:/djgpp/src/bash-2.05b/djbuild/../variables.c:1360
0x00015548 find_variable_internal
c:/djgpp/src/bash-2.05b/djbuild/../variables.c:1393
0x000155b0 find_variable
c:/djgpp/src/bash-2.05b/djbuild/../variables.c:1405
0x00038f99 nofork_restore_all_environment
c:/djgpp/src/bash-2.05b/djbuild/../nofork.c:249
0x0001ec43 command_substitute
c:/djgpp/src/bash-2.05b/djbuild/../subst.c:3926
0x00021461 expand_string_unsplit_to_string
c:/djgpp/src/bash-2.05b/djbuild/../subst.c:6120
0x0013bdc8 __tty_screen
??:0
0x000549e1 inttostr
../../../lib/sh/itos.c:39

hashlib.c:
/* Return a pointer to the hashed item. If the HASH_CREATE flag is passed,
create a new hash table entry for STRING, otherwise return NULL. */
BUCKET_CONTENTS *
hash_search (string, table, flags)
const char *string;
HASH_TABLE *table;
int flags;
{
BUCKET_CONTENTS *list;
int bucket;
unsigned int hv;

if (table == 0 || ((flags & HASH_CREATE) == 0 && HASH_ENTRIES (table) == 0)) /* <--- !!! This is line 175!!! */
return (BUCKET_CONTENTS *)NULL;

bucket = HASH_BUCKET (string, table, hv);


Disassembly shows that that table is corrupted at line 175
(0xcfcfcfcf).

Any thoughts? Let me know what else I can do to help
debug this.

If you compile bash yourself, you'll get debug info in it and can run
it in gdb.

Doing that, it reveals to me that it seems to be some kind of
corruption that happens somewhere in excute_cmd.c:
execute_simple_command() or in what is called from there. A watchpoint
tells me that it's changed in nofork.c: nofork_save_all_environment()
and nofork_restore_all_environment(). But that does not seem to be the
place of corruption.

So it's not clear to me exactly why/shen that happens and as gdb have
trouble handling this part of the executable (it seems to swap stacks)
and likes to hang, you're welcome to try to figure it out.

Or perhaps someone that is more familiar with bash's inner workings
can?


Right,

MartinS
.

Relevant Pages