Date: Sun, 7 Nov 1999 17:19:45 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Forsberg Sakari <zacu AT cc DOT tut DOT fi>
cc: djgpp AT delorie DOT com
Subject: Re: Some error messages when using dialog...
In-Reply-To: <7vuud6$7jg$1@baker.cc.tut.fi>
Message-ID: <Pine.SUN.3.91.991107171920.12805Z-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On 5 Nov 1999, Forsberg Sakari wrote:

> Could following error information be a sign that
> my program uses char-arrays or some other
> arrrays over their boundaries?

Not necessarily.

It is true that cerashes inside `free' usually mean what you suspect
it means, but in this case, the situation is complicated by the fact
that the program got stuck in an endless loop, from which you bailed
out by pressing Ctrl-C.

So the crash inside `free' might not be the real reason for the bug,
just a consequence of some other bug which was the reason for the
endless loop in the first place.

You need to find out why did your program enter an endless loop.

> Call frame traceback EIPs:
>   0x00078c93   _free+247
>   0x00074254   ___builtin_delete+16, line 0 of libgcc2.c
>   0x0001461d   __$_13dialog_object+25
>   0x00077f75   _exit+69
>   0x0007a20d   _int86+2669
>   0x0007a6e9   ___djgpp_traceback_exit+145
>   0x0007a76a   _raise+94
>   0x0002d331   __set_vga_virtual_width+309
>   0x0007a7b6   ___djgpp_exception_processor+26
>   0x001829d0   0x1829d0
>   0x00074254   ___builtin_delete+16, line 0 of libgcc2.c

All of the stack frames above __djgpp_exception_processor+26 are not
relevant to the endless loop: they all are triggered by Ctrl-C.  What
happens after Ctrl-C is that it generates SIGINT, for which your
program seems to install a handler, _set_vga_virtual_width.  That
function does its thing and then raises a fatal signal, probably the
same SIGINT, that this times wants to exit the program.  The final
crash is inside the static destructors of some of your objects.

But the real problem is here:

>   0x001829d0   0x1829d0
>   0x00074254   ___builtin_delete+16, line 0 of libgcc2.c

What is this strange 0x1829d0 on the stack?  Looks like
__builtin_delete got severely confused by something, but by what?

It might help to see more levels of the stack traceback.  To this end,
run your program like this:

    redir -e error.log ilmari.exe [put any arguments here]

When the standard error stream is redirected to a file, the DJGPP
crash traceback is printed in its entirety, because there's no danger
that it will scroll off the screen.  Examine the file error.log after
the program crashes, and find the topmost line which is in your code.
This should be a good place to start debugging, because something
there wreaks havoc in the library functions.