Message-ID: <387D90EF.1D5B0DCB@mpx.com.au> Date: Thu, 13 Jan 2000 19:46:39 +1100 From: jazir 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: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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.