Mail Archives: djgpp/2001/01/22/06:51:32
In addition to the hints given by Eli already, let me point at a few
more issues that jumped to my eye:
Florian X <dos DOT fire AT aon DOT at> wrote:
> Call frame traceback EIPs:
> 0x000a9b9f _free+247
> 0x000016c4 _sf_free+24, line 81 of program.c
> 0x00003d38 _dispose+52, line 1478 of program.c
> 0xffd94c14 0xffd94c14 <------------- funtktion in the DLX program
> 0x00003d23 _dispose+31, line 1476 of program.c
This *may* be part of your problem. Note that dispose() is being
called recursively, with only that slightly volatile 'DLX program' in
between. Iff that routine uses any kind of non-volatile storage in a
way DLX doesn't expect, this could get you in trouble.
> I used it, but they couldn't show me more infos, because of the DLXs
> and because some *.c files are included into the main file program.c
> via fe. #include"object.c".
Two solutions to that:
1) use -gstabs+ or -ggdb instead of -g in GCC
2) Don't #include *.c files into one another. It's bad style, anyway.
> Yes, I tried it. I think it tries to remove a memory block which wasn't
> right allocated via malloc.
Or which got its internal bookkeeping datastructures damaged. For this
type of problem, YAMD would be my recommendation. If it's possible to
run your app under YAMD, it'll find the bug much more quickly than you
can do it yourself using code-snippeting. It'll crash your app exactly
at the point where it tries overwrites crucial stuff.
> All free() commands where replaced by a macro like this:
That macro does nothing useful on DJGPP. You might want to get rid of
it.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -