Mail Archives: djgpp-workers/2001/08/25/04:38:23
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
- Raw text -