Mail Archives: djgpp/2003/07/17/11:03:10
> From: Jan Vanrie <Jan DOT Vanrie AT psy DOT kuleuven DOT ac DOT be>
> Newsgroups: comp.os.msdos.djgpp
> Date: Thu, 17 Jul 2003 15:32:21 +0200
>
> Page Fault at eip=000c11dd, error=0004
> eax=bc040400 ebx=0045e0dc ecx=0061ade4 edx=bc1a1a4c esi=0061ade4
> edi=2f010100
> ebp=002667f8 esp=002667ec program=C:\SRC\DOTS2002\DOTREAD.EXE
> cs: sel=00af base=83dde000 limit=ffaf1fff
> ds: sel=00b7 base=83dde000 limit=ffaf1fff
> es: sel=00b7 base=83dde000 limit=ffaf1fff
> fs: sel=00c7 base=00000000 limit=0010ffff
> gs: sel=00c7 base=00000000 limit=0010ffff
> ss: sel=00b7 base=83dde000 limit=ffaf1fff
> App stack: [002677c4..001677c4] Exceptn stack: [00167718..001657d8]
>
> Call frame traceback EIPs:
> 0x000c11dd free+245, file malloc.c
> 0x0006d30e destroy_bitmap+370, file c:/djgpp/allegro/src/graphics.c, line 1165
> 0x0001a04e sequence_trial2(trial*)+3626, file c:/src/dots2002/sequencetrial.cp
> 0x0005f98a .debug_pubnames+42821, file c:/src/dots2002/exp.cpp, line 730
> 0x00033809 .debug_info+613, file c:/src/dots2002/irpreter.cpp, line 1006
> 0x00024d51 .debug_line+817, file c:/src/dots2002/irpreter.cpp, line 211
> 0x00023d59 interprete(std::string)+391, file c:/src/dots2002/irpreter.cpp, lin
> 0x0002366a cl()+250, file c:/src/dots2002/irface.cpp, line 74
> 0x0002323e irface(int)+62, file c:/src/dots2002/irface.cpp, line 22
> 0x00068a3a main+4576, file c:/src/dots2002/dotread.cpp, line 157
> 0x000bc758 __crt1_startup+176, file crt1.c
>
> 0X0001a04e -> 117 destroy_bitmap(fixpage); fixpage=NULL;
>
> x/i 0xc11dd <free+245>: mov 0x16164c(%eax),%eax
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.
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.
- Raw text -