Re: segmentation fault when window closes

[Piscium <groknok gmail com>]

On 23 September 2010 12:55, Chris Vine <chris cvine freeserve co uk> wrote:
> On Wed, 22 Sep 2010 23:14:20 +0100
> Piscium <groknok gmail com> wrote:
>> I created a example program to summarize the relevant details of my
>> application. It is listed below. Interestingly the example does _not_
>> crash. But I must be doing something wrong, and the fact that the
>> example does not crash must be a coincidence. I wonder if anybody can
>> spot what is wrong?
>
> The cause of your segfault is not connected with this code.  The problem
> with memory handling errors is that they usually create a segfault some
> distance from the source of the error (often at the point when an
> access is made to already freed memory which no longer forms part of
> the memory image of the running program or which causes the program to
> try to read memory or jump to code outside its image and/or its code
> block, or to dereference a null pointer).
>

After spending hours tracing through header files in STL, looking at
ustring source code, reading basic_string documentation plus
information on ctors and dtors, it turned out the problem was ...
elsewhere.

Basically I have an embryonic C application that I am partly
converting to C++ and re-architecting as OO. I have a C function that
takes as parameter a pointer to an array of doubles where it stores
the calculations. I created a new function that takes a pointer to a
single double to be used by the new C++ object. Unfortunately I made a
mistake and was still using the old function, which meant that the
memory of C++ objects was being corrupted by the old C function.

As in the visualization functions I am still using the old C function
(not the new objects), everything looked normal. It was only at the
end of the program when the vector dtor was busy destroying objects
that the problem became apparent.

The reason the crash did not happen when I commented out the ustring
is because that was the only class member that was not of a primitive
type (the others are ints and double) so there was pointer
de-referencing. And the reason my example program was not crashing was
because it did not have the offending C function.

I read somewhere, possibly in M. Cline's FAQ, a warning against
converting a C application to C++. I heard the lesson! It is not that
I will stop what I am doing, because this is just a hobby to learn new
things, but I will have to be more careful.

Thanks to Rob, Chris and Murray for your comments.