Date: Sat, 19 Jul 2003 13:46:04 +0200
From: "Eli Zaretskii" <eliz AT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: peter DOT claessens AT psy DOT kuleuven DOT ac DOT be
Message-Id: <2110-Sat19Jul2003134603+0300-eliz@elta.co.il>
X-Mailer: emacs 21.3.50 (via feedmail 8 I) and Blat ver 1.8.9
CC: djgpp AT delorie DOT com
In-reply-to: <3F17E974.70004@psy.kuleuven.ac.be> (message from Peter Claessens
	on Fri, 18 Jul 2003 14:35:00 +0200)
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> <3F17E974 DOT 70004 AT psy DOT kuleuven DOT ac DOT be>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Fri, 18 Jul 2003 14:35:00 +0200
> From: Peter Claessens <peter DOT claessens AT psy DOT kuleuven DOT ac DOT be>
>  
> 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

This means that either the dereference of `a' in "a->size" or whatever
ENDSZ(a) does caused the crash.  Since "a->size" only _reads_ from the
address pointed to by `a' ("a->size" being on the right side of the
assignemnt), it's not where the crash happens, since we have this
line in the crash message:

> Page Fault at 0x0006939c, error=0006

"error=0006" means the crash happened when the program tried to
_write_ to some address, and that address was found to be invalid.

So, looking at the definition of ENDSZ:

> #define ENDSZ(bp)	(*(size_t *)((char *)bp + bp->size + 4))

We see that it dereferences puts a value into the address computed
like this:

     a + a->size + 4

`a' is almost certainly a good pointer, since otherwise the program
would have crashed when it computed "a->size".  Therefore, if you
print the value of "a->size", you will most probably see a garbled
value, probably produced by some code that overwrote the value
recorded there by malloc.  (a->size records the size of the allocated
buffer.)

Now the trick is to put a watchpoint at the address of a->size, and
then run the program again.  Then you will see what code writes a
bogus value there.

> Unfortunately, if I put a watchpoint on 0x6939c or on 0x5ecfa24, gdb 
> freezes or crashes badly in the run.

0x6939c is an address in the code section, so you cannot usefully
watch it.  And as the analysis above suggests, 0x5ecfa24, which is the
value of `a', is not part of the problem; a->size is.