Message-ID: <3F17E974.70004@psy.kuleuven.ac.be>
Date: Fri, 18 Jul 2003 14:35:00 +0200
From: Peter Claessens <peter DOT claessens AT psy DOT kuleuven DOT ac DOT be>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: nl-BE,en
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: malloc/free blues
References: <3F156434 DOT 3000508 AT psy DOT kuleuven DOT ac DOT be> <uu19m75gm DOT fsf AT elta DOT co DOT il> <3F159AC9 DOT 4010402 AT student DOT kuleuven DOT ac DOT be> <3405-Thu17Jul2003062928+0300-eliz AT elta DOT co DOT il> <3F16A565 DOT F77DA70E AT psy DOT kuleuven DOT ac DOT be> <9003-Thu17Jul2003180038+0300-eliz AT elta DOT co DOT il>
In-Reply-To: <9003-Thu17Jul2003180038+0300-eliz@elta.co.il>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by KULeuven Antivirus Cluster

This last line means that the EAX register is garbled. I suspect that

>some code writes past the end of an allocated buffer; you should
>review your code and look for such code.  Typical cases include:
>allocate of an array of size N, then put data into more than N
>elements; destroy an object more than once; destroy an object that
>wasn't allocated (a.k.a. ``uninitialized pointer''); put more data
>into an object than the object can hold; use of `malloc' instead of
>`new' to allocate C++ objects.
>
I have some thousands lines of code, so it's quite hard to find it this 
way if I don't really know where to look... therefore I tried your next 
suggestion:

>
>If none of the above helps, I suggest the following (somewhat painful)
>procedure to find the offending code:
>
>  - download djlsr203.zip, extract the module malloc.c from it, and
>    paste its code into your program's sources;
>  - rebuild the prfogram and run it under GDB;
>  - when the crash happens, find the address of the data that is
>    corrupted by looking at the malloc data structures that cause the
>    crash inside `free';
>  - put a watchpoint on the address that gets corrupted, and run the
>    program again.  GDB will stop the program each time that address
>    is written and show you what code did that.
>  
>
A typical traceback with included malloc.c:

Page Fault at 0x0006939c, error=0006
eax=0020fcc8 ebx=000085a4 ecx=003c2604 edx=005d22d0 esi=00000054 
edi=00167bcc
ebp=001e6a68 esp=001e6a50 program=C:\SRC\DOTS2002\DOTREAD.EXE
cs: sel=00af  base=85a44000  limit=ff07dfff
ds: sel=00b7  base=85a44000  limit=ff07dfff
es: sel=00b7  base=85a44000  limit=ff07dfff
fs: sel=00c7  base=00000000  limit=0010ffff
gs: sel=00c7  base=00000000  limit=0010ffff
ss: sel=00b7  base=85a44000  limit=ff07dfff
App stack: [001e7bcc..00167bcc]  Exceptn stack: [00167b10..00165bd0]
 
Call frame traceback EIPs:
  0x0006939c merge(BLOCK*, BLOCK*, BLOCK*)+170, file 
c:/src/dots2002/mallocsrc.c
  0x000678e1 free+141, file c:/src/dots2002/mallocsrc.cpp, line 312
  0x0006d94e destroy_bitmap+370, file c:/djgpp/allegro/src/graphics.c, 
line 1165
  0x000133d5 .debug_str+544, file c:/src/dots2002/grafx.cpp, line 2496
  0x0005f98a .debug_pubnames+42777, file c:/src/dots2002/exp.cpp, line 731
  0x00033809 .debug_info+613, file c:/src/dots2002/irpreter.cpp, line 1006
  0x00024d51 .debug_line+581, file c:/src/dots2002/irpreter.cpp, line 211
  0x00023d59 interprete(std::string)+391, file 
c:/src/dots2002/irpreter.cpp, lin

In GDB this looks like:
SIGSEV, Segmentation Fault at 0x0006939c in merge(a=0x5ecfa24, 
b=0x6e971c, c=0x5eca24)
mallocsrc.cpp:273: ENDSZ(a)=a->size

Maybe this tells you something about what is happening. I don't know 
what the parameters in merge stand for, and which of these 4 adress 
values I should watch.
Unfortunately, if I put a watchpoint on 0x6939c or on 0x5ecfa24, gdb 
freezes or crashes badly in the run.
I will also try your other suggestion (examining the ASCII string value).