program crashing randomly code -1073741819

[feraudyh]

Hello,
I have written a Windows XP Qt app and it occasionally crashes when it tries to connect to Postgres.
There are several ways it crashes, sometimes the main window closes and other times I get a more polite message box before it crashes.
I tried putting in a trace with QMessageBox::information inside various parts of my
"dbConnect()" function, but it has always worked when these have been enabled
(to remove them I used
#define TRACE()
)
I have never seen it crashing inside the deebugger either.
I'm wondering about how to go about hunting for my bug.

I've heard that there are programs like Rational Purify and Valgrind
that could help me point to the error, but I'm running on a small budget.
What do Qt developpers do, apart from looking at their code very carefully?

By the way the last time it crashed it left an error code inside Qt Creator:
-1073741819

[tbscope]

That error corresponds to 0xc0000005 which is an access violation error.
This means you try to access a section of the memory that is not available to you.
This in turn happens when you use uninitialised pointers.

These can easily be found by checking your code manually.
If not, by running the code in a debugger.

But since you mention possible other errors (no crashes?) the problem might be even worse.
To give you more information, please provide a minimal compilable example demonstrating the errors.

[feraudyh]

Thanks,
The fact that it is an access violation error is very useful to me, at least I know that it's not an out of memory error.
I suppose I can spend an evening looking at all pointers to see where they are initialised.
The code is too big to post up here and it is written in my contract that I cannot show my code (in any substantial way).
I had a lot of experience in plain old C a long time ago and knew that in a debugger some errors just went invisible.

I wonder if it's of any use to initialise all pointers to NULL as soon as possible if you cant see where
they are initialised.
At least the app might crash sooner.

I was also wondering: if I ported my app to Ubuntu then I might see the bug more easily.
I might get a core dump for example.

[feraudyh]

I've just had an idea as to why my program may be crashing, I'd like your opinions.
I have a class called Parser. It has a constructor with a string argument and a parse method that returns a "geometry"(this is for a GIS app). The geometry is the result of parsing the string that is represented by the string. My class is allocated locally on the stack as in Parser p(myString) The parse() returns to a pointer member called m_geometry.
This geometry is read by the app, but quite often (about 6 times) p goes out of scope, and yet the geometry is supposed to be still valid. I used new to create the geometry.
Is there a risk that the geometry is no longer valid when p is no longer in scope?

[Zlatomir]

Is there a risk that the geometry is no longer valid when p is no longer in scope?

It's most likely that the data gets corrupted (but it depends)

If you copied only the pointer (and not the data that the pointer refer to) than this might be the reason for accessing memory you don't own and get "access violation error".

If you didn't delete the pointer when it gets out of scope (in it's containing class destructor) then you will have a memory leak (in this case you shoudn't get "access violation error" since the memory is yours (but i call "bad practice" to use one pointer to allocate on heap and a copy of that pointer to delete the resource)

[feraudyh]

Thanks.
I'll have a look.

[feraudyh]

OK I found a big error and it runs much better.
It was a classic:
I was doing a strcpy from a char * whose length was n bytes into a zone that had n characters allocated. Now I had not allocated for the extra character ascii 0 at the end.
Must have been tired when I wrote that.

I found my bug by inserting trace macros into the code defined as this
#define TRACE(Fn) traceWrite(tr("MainWindow.cpp, Line %1").arg(__LINE__))
traceWrite writes into a stream and flushes after every write.
This means I could find the vicinity of the error quickly.