Thread: 0xc0000005 error

Hi there!

I have a problem which I can't really solve. I wrote a program (quite complicated one), which generates the mentioned 0xc0000005 error, upon starting the compiled exe, and says "failed to initialize properly".
The weird thing is, that this happened after I began having trouble with the exit(0) command. Whenever I close my program not using the X button, I used this command to solve the problem. But this time (I don't know why) this command does NOT stop the program from running even though all the forms were destroyed.
Can you help me with that? Did you have any problems like this in the past?
I use Borland C++ Builder 5.0, and havent run into anything like this before.

Thx guyz!
Attila

Thx, I suspected the same, and checked the arrays I'm using. They look okay. I avoid using pointers, so that shouldn't be a problem.

And can you help me in determining why the exit(0); command does not work? Application->Free() however works (no matter how illegal it is).
There surely is some memory issue, somehow Free is not called automatically. Have you run into anything like this?

Thx again.

Originally Posted by Hankyaku

Thx, I suspected the same, and checked the arrays I'm using. They look okay. I avoid using pointers, so that shouldn't be a problem.

If you avoid using pointers, the most likely problem is falling off the end of an array. It is also possible you're doing something with I/O (eg fscanf() being supplied an int when it expects a double due to %f format specifier) that overwrites something you don't intend.

Originally Posted by Hankyaku

And can you help me in determining why the exit(0); command does not work? Application->Free() however works (no matter how illegal it is).
There surely is some memory issue, somehow Free is not called automatically. Have you run into anything like this?

Like matsp said, possibly a side effect of your other problem: your misbehaving code is tromping some memory that exit() needs to function.

Thanks guys, I'll check that. I'm using a TeeChart in the software, that may cause some trouble. I'll begin //-ing my code and see what happens. Hell of a job at many forms and few thousand lines.

Hi!

It seems that I've solved this issue. But I don't understand how it works. So please, if anybody of you can come up with any guess, please don't hesitate to share!!!

It happened like this. I ran the compiled exe files on my pendrive in different directories, and I found that at a location it work, while it didn't work at the other one. I began filtering the system files (and abandoned the guess that XLSReadWrite does cause any trouble), and found that once I removed vcl50.bpl, and left vclx50.bpl in the directory of the exe, it worked! But as soon as I copied it back, it gave the initialization error.

Now how weird is that? I'll run further test to check if this really was the problem, or my program called anything in this bpl I'll miss later on. But if you have any guesses, please share! (I don't really know much about this file at all...)

Cheers!
Han

vcl50.bpl is a library that contains basic GUI controls and vclx50.bpl contains some more rarely used controls (Checklst, Colorgrd, Ddeman, Filectrl, Mplayer, Outline, Tabnotbk, Tab) for an application built using C++ Builder 5. If required, they are usually statically linked in (and the associated error message at run time if you have problems with version of those, or if they don't exist, will be to the effect of a required library not found, not a pointer related error).

I'd guess you actually have (at least) problems.

1) In BCB, look at Project/Options. Under the linker tab, if you uncheck "Use Dynamic RTL" your executable will be statically linked and not require those libraries. It will create a larger executable though.

2) I would still strongly suspect the real cause of your problem is still a pointer molestation or array overrun. The sensitivity to libraries is more likely a side-effect: by moving dynamic libraries around you will be changing minor things related to final memory layout when your executable is finally loaded, so the memory that is being tromped subtly changes and therefore the symptom changes.

Thanx for the info.
The situation is sooo interesting. I say this because this error showed up only recently. Those applications I made earlier began producing this error messages recently.
I didn't make any real modifications to them concerning pointer usage. Actually I don't even use pointers. I use arrays, but at an array index overflow I immediately get an exception. So that's why I was shocked.

Array index overflow does not automatically give exceptions; such things, in practice, only happen in a specific set of circumstances.

Probably all that's happened is that you made some small change in your program recently (eg addition of some new variables, or something, and operations on them). That would change the memory layout of your program. So the real culprit is having a different effect from what it did originally (i.e. becoming visible when it wasn't before).

It is also possible you changed some data file used by your program, and that is affecting some critical data in a way you didn't anticipate. This is quite common if the process of reading your data involves allocation and deallocation of memory (eg clearing a dynamically allocated list and then growing it again to store new data).

These are interesting.
I mean of course I did insert new variables, and assigned some functions as well. But I use static arrays, and this makes such overflows (as far as I know) impossible, as if I try to write to them I'd run into exceptions upon programming, not only upon execution (since nothing changes, but in one case I compile&run&debug, and in the other I just run the exe).
Is there anything in C builder which would make these kind of errors traceable during development? Is there a way I can monitor the memory usage of my program? I didn't really need to use advanced C builder features until now...