Mail Archives: djgpp/2003/07/18/08:35:29
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).
- Raw text -