X-Authentication-Warning: new-smtp2.ihug.com.au: Host p376-tnt4.syd.ihug.com.au [203.173.135.122] claimed to be acceleron
Message-ID: <003701c12d40$a4d1e320$0a02a8c0@acceleron>
From: "Andrew Cottrell" <acottrel AT ihug DOT com DOT au>
To: <djgpp-workers AT delorie DOT com>, "Mark E." <snowball3 AT bigfoot DOT com>
References:  <002801c12892$0badcb80$0a02a8c0 AT acceleron> <9003-Sun19Aug2001152113+0300-eliz AT is DOT elta DOT co DOT il>
Subject: Bash 2.05 beta 23-Aug-2001 with Win 2K
Date: Sat, 25 Aug 2001 18:33:39 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Reply-To: djgpp-workers AT delorie DOT com

All,

Today I have had time to have a look at the problem with Bash running on Win
2K. I did some testing and then checked for updates and found that there was
an update from the 23-Aug-2001 which I downloaded and compiled. There are
some very interesting memory corruption quirks I have found. These are
bizare to say the least.

Mark this looks like another Win 2K specific problem.

They quirks I found were:

1) If I add a debugging printf in the array_init() function then I can get
bash to start re-configuring GREP 2.4. The modified array_init()  is:
    static void
    array_init(struct dynamic_array *array, const char *s, size_t size)
    {
      array->start = malloc(size + 1);
      array->ptr = array->start;
      array->end = array->start + size;
    #if 1
    printf("%s %d , array->start = %d ,array->end = %d, malloc(%d)\n",
               __FILE__, __LINE__, array->start, array->end,  size+1);
    #endif
      if (s)
        array_puts(array, s);
    }

Even more puzzling is if I remove the printf then Bash crashes if LFN=y, but
does not crash if LFN=n

2) When exiting Bash I get a SIGSEV crash in restore_cwd(). To fix this I
initalise init_cwd to NULL as per the following line:
static char *init_cwd = NULL;
The strange part is that if I do not initialise init_cwd to NULL in
save_cwd() function if I put printf's they  show that init_cwd is NULL even
if I do not explicity initialise it to NULL.

I just modifed glob.c to check out the lfn usage and now I do not need to
initialise init_cwd.

The following is the printf's from save_cwd():
dospath.c 212 save_cwd= (null)
++++++dospath.c 216 getcwd= d:/dj204/gnu/grep-2.4
>>>>>>dospath.c 218 init_cwd= d:/dj204/gnu/grep-2.4

The following is the SIGSEV crash:

Exiting due to signal SIGSEGV
General Protection Fault at eip=0007e457
eax=00000003 ebx=2c203633 ecx=2c203633 edx=000371ec esi=ffffffff
edi=00000000
ebp=0011c5cc esp=0011b1a4 program=D:\DJ204\GNU\GREP-2.4\BASH.EXE
cs: sel=24df  base=01fc0000  limit=0015ffff
ds: sel=24e7  base=01fc0000  limit=0015ffff
es: sel=24e7  base=01fc0000  limit=0015ffff
fs: sel=24b7  base=00005ce0  limit=0000ffff
gs: sel=24f7  base=00000000  limit=0010ffff
ss: sel=24e7  base=01fc0000  limit=0015ffff
App stack: [0011c6f4..0009c6f4]  Exceptn stack: [0009b8cc..0009998c]

Call frame traceback EIPs:
  0x0007e457 __doprnt+2367
  0x0006d74c _printf+28
  0x00037210 _restore_cwd+32, line 399 of dospath.c
  0x0006d197 _exit+39
  0x000020e6 _exit_shell+62, line 811 of shell.c
  0x00001d34 _main+1664, line 647 of shell.c
  0x0006cd6f ___crt1_startup+203

I thought this may be an issue with the new array code in dospath.c , but is
does NOT have any LFN conditional code or checks for osmajor etc.....

Any ideas on this one? Besides it's a memory corruption needle in a haystack
issue. Whould  yamd be worth trying?

Andrew