Mail Archives: djgpp/1998/04/02/00:46:33
Eric J. Whitney wrote:
>
> Call frame traceback:
> In function free+14
> In function __builtin_delete+16
> In functon __builtin_vec_delete+11
> es.cpp(153) in function SetSize_t5Array1ZfUs
> es.cpp(17) in function __t5Array1ZfUs
> es.cpp(142) in function main
> in function __crt1_startup+138
>
> What have I done wrong??? It runs fine with one instance of the
> Matrix, but for two, it crashes!!!
> I have stepped through it using F8 and it always crashes right where the
> second matrix is initialised.
Without actual sample code that we can compile and test for ourselves,
there's no way to be certain what your problem is. I can certainly make
some guesses, though:
- Make sure your template constructors are calling new with the correct
type; allocating too much or too little memory could cause crashes.
- According to that traceback, the crash occurs in free() which is
called by delete, which is called from Array::Setsize(). Therefore,
check that Array::SetSize() is calling delete with a valid pointer
argument that was allocated by new.
- It doesn't look like it, but just in case: if the Matrix instances
take up large amounts of memory you could be suffering a stack
overflow. Chapter 15.9 of the FAQ describes this phenomenon and how to
correct it.
- Improper initialization and other subtle mistakes can be the cause of
so many hard-to-debug crashes. Make sure you compile with the maximum
possible warning options: '-Wall' and '-O' are the basic ones, but
'-W', '-ansi', and '-pedantic' can be used in extremis.
- When you run your program under RHIDE and it crashes, try examining
the stack frame of Array::SetSize() to make sure all variables are what
they are supposed to be. If you don't see anything useful, set a
breakpoint in Array::SetSize() and step through the function one line at
a time with watches enabled on all local variables.
If the source of the error still doesn't become clear, try to come up
with the smallest possible piece of code that can be compiled and that
reliably exhibits the crash and post it here; we'll take a crack at it.
One other question: if your classes throw exceptions, and you run them
in a try...catch block, you may encounter bugs in DJGPP's support for
gcc 2.8.0's exception handling. (This shouldn't cause a crash, but
still could be causing some kind of problem.) The fix is to compile
with '-sjlj-exceptions' (sp?), and wait for a patch to fix the bug.
hth
--
---------------------------------------------------------------------
| John M. Aldrich | "Always listen to experts. They'll |
| aka Fighteer I | tell you what can't be done, and why.|
| mailto:fighteer AT cs DOT com | Then do it." |
| http://www.cs.com/fighteer/| - Lazarus Long |
---------------------------------------------------------------------
- Raw text -