Mail Archives: djgpp/2006/08/15/15:18:12
Gordon DOT Schumacher AT seagate DOT com 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
- Raw text -