Message-ID:	<387D90EF.1D5B0DCB@mpx.com.au>
Date:	Thu, 13 Jan 2000 19:46:39 +1100
From:	jazir <entropic AT mpx DOT com DOT au>
X-Mailer:	Mozilla 4.5 [en] (Win95; I)
X-Accept-Language:	en
MIME-Version:	1.0
To:	djgpp AT delorie DOT com
Subject:	Re: upgrade chaos
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 1000112154156 DOT 258A-100000 AT is>
Reply-To:	djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> On Wed, 12 Jan 2000, jazir wrote:
> 
> >   i'm willing to accept that my code is buggy, so i'll do
> > my best at finding it.  however, it was v2.02 that i upgraded
> > from.
> 
> Then it is a little bit less evident, but I cannot really tell without
> seeing the full crash message.  Can you post it?

Yep I can do that.  Firstly I'd like to say that YAMD is a great program,
as it helped me find memory leaks...but there were no msg'es about accessing
memory not belonging to my program.  Once I had the leaks sorted, the only
output was for successful allocation and deallocation of blocks.

In fact, when I compiled my program with YAMD, everything worked as expected.
There was no crash..that could just mean that my bug goes back to doing no
damage, as in djgpp v2.02, but YAMD should still detect it... i'm puzzled.

Here is the symify'ed output for two different runs {compressing different 
files}.  As you can see, one GPF occurs in malloc, the other in free.

Exiting due to signal SIGSEGV
General Protection Fault at eip=00004d9f
eax=0009edd9 ebx=000bf21c ecx=000bf24c edx=000bf244 esi=00000028 edi=00000028
ebp=000984e0 esp=000984d0 program=C:\PROGRA~2\UTILS\PACK\PACK.EXE
cs: sel=00a7  base=82ff1000  limit=000cffff
ds: sel=00af  base=82ff1000  limit=000cffff
es: sel=00af  base=82ff1000  limit=000cffff
fs: sel=0087  base=00008390  limit=0000ffff
gs: sel=00bf  base=00000000  limit=0010ffff
ss: sel=00af  base=82ff1000  limit=000cffff
App stack: [00098760..00018760]  Exceptn stack: [000186b4..00016774]

Call frame traceback EIPs:
  0x00004d9f _malloc+99
  0x000018ba _bsOpen+18
  0x000032ec _writeSymbols+20
  0x000028e2 _outputFile+338
  0x00002d1e _main+506
  0x00004956 ___crt1_startup+178

-----------

Exiting due to signal SIGSEGV
General Protection Fault at eip=00004ffb
eax=210e2c40 ebx=000203ec ecx=000203ec edx=210f5e74 esi=000beffc edi=08438b10
ebp=00098500 esp=000984f4 program=C:\PROGRA~2\UTILS\PACK\PACK.EXE
cs: sel=00a7  base=82ff1000  limit=0011ffff
ds: sel=00af  base=82ff1000  limit=0011ffff
es: sel=00af  base=82ff1000  limit=0011ffff
fs: sel=0087  base=00008390  limit=0000ffff
gs: sel=00bf  base=00000000  limit=0010ffff
ss: sel=00af  base=82ff1000  limit=0011ffff
App stack: [00098760..00018760]  Exceptn stack: [000186b4..00016774]

Call frame traceback EIPs:
  0x00004ffb _free+119
  0x000019f5 _bsClose+181
  0x000033e5 _writeSymbols+269
  0x000028e2 _outputFile+338
  0x00002d1e _main+506
  0x00004956 ___crt1_startup+178


I just ran the program on yet another file.  It worked the first time, but
crashed the second time, with a result the same as the second one above.
It makes things even harder when the bug doesn't appear every time, even if
the program input is the same.

Is there a possibility I had the old malloc+free in a v2.02 distribution?
It still seems mostly likely that the GPF is caused by my code.


> This usually means a hardware problem.  GCC is a memory hog: it uses lots
> of RAM, and it shuffles large buffers to and fro.  It is not uncommon for
> it to be the first application that crashes when something is wrong with
> memory or CPU cache setup.

yep thanks for that..i got a similar response from the GCC-Bug people, though
with a few insults about the OS i'm using ;)

thanks again,
jazir.

- Raw text -