X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-ID: <44e21a48$0$489$cc7c7865@news.luth.se>
From: Martin Str|mberg <ams AT speedy DOT ludd DOT ltu DOT se>
Subject: Re: That BASH crash, revisited
Newsgroups: comp.os.msdos.djgpp
References: <OF61A52282 DOT CB39175D-ON872571C4 DOT 006931B1-872571C4 DOT 0070EA32 AT seagate DOT com>
User-Agent: tin/1.4.6-20020816 ("Aerials") (UNIX) (NetBSD/1.6Q (alpha))
Date: 15 Aug 2006 19:02:32 GMT
Lines: 114
NNTP-Posting-Host: speedy.ludd.ltu.se
X-Trace: 1155668552 news.luth.se 489 130.240.16.13
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

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