I prefer to use PSPad (basically a glorified Notepad) to write my code and complie it with Borland C++ 5.0 since it's open source. My program reads in data from a file, processes it, then stores it in an vector of objects. The program crashes when I read in 27 lines. I then switched over to CodeWarrior so I can debug and step through my program. To my surprise, the program works completely fine irregardless of how many lines I read in. Why is there a compiler discrepancy? When I hit debug and chose MS Visual Studio 2005 (I have a student's version but don't like it very much) the log stated that I had multiple access violations at 0xfffffffa. What does that mean? On a side note, is stack size compiler dependent or machine/OS dependent? Is that why my program crashes with Borland and not CodeWarrior? If you run out of stack space will you automatically start using the heap?

I was having somewhat of the same problem earlier. My code also crashed when compiled with VC++, but not with MinGW. It turned out I was using delete on a pointer that had already been deleted. Chances are you aren't checking for possible errors along the way or you're doing something like I did that's known to cause errors.

As for your other questions, I can't help you there.

Quote:Original post by Alpha_ProgDes
Show da code!

It's like 400 lines long and I'm not sure where it's crashing since I can't step through with the Borland compiler.

I can already guess exactly what is happening based on the error.

Codewarrior is initializing memory by clearing it to zero. This may be a normal behavoir, it may be because you have a debugging setting set (most likely the second). Borland is not wasting time in your code initializing memory to zero, either because it is in a release setting, or because it is not considered a useful debug setting (it does after all create odd debug/release differences).

This has likely resulted in one of two types of bugs.

One type is a pointer bug, where you have a pointer test (or a free operation, which does a pointer test to see if there is actually memory to free), and that is failing because there is a garbage value (it attempts to free memory that is not allocated, or assumes an object has been initilized because it is not null, when in fact it is just pointing to random memory).

The other type is that you are not initializing your variables to known value, resulting in unusual behavoir. One example might be an array index. With memory zeroed, it initially points to the first element in the array. When not, it can point to the 11 millionth element, which does not exist and causes an exception. There are many ways variables with unpredictable values could affect your code, ultimately leading it down a path leading to an access violation.

Please, show the code, so that something can be learned. "over 400 lines" is not a problem; that's what [source][/source] tags are for.

You may not be able to step through, but you'd be surprised how much you can accomplish with print statements :D