Hello jcl,

I resisted writing thread for three months now, trying to get to the bottom of it myself, but I'm finally all out of ideas and really need your help with it. I've contacted support before without getting into detail about the problem (thinking it had to do with mallocs) but that doesn't seem to be the case anymore..

I've been getting random E15E13 crashes all over my code, in functions that really seem to be fine. And it only gets weirder after this..

I can manage to get it crash at the same line every time I run it. Without changing the code, I then play with the nexus size a bit, and the crash will disappear or happen in another function. Also, sometimes I get the crash to happen much less frequently just by running my project using a bat file command: "C:\Program Files\GStudio7\acknex.exe" myproject.c, instead of running it from WED/SED. Finally, I sometimes got the crash to disappear just by declaring a new array to my scripts, f.e.: "var dummyarray[100000];"

I've done a lot of looking around in the forums and saw your responses to similar problems about being a memory problem/uninitialized pointer, smth like that.. I went ahead with removing all sys_mallocs from my project with no effect. I also removed other suspicious actions like running functions using function pointers, replaced structs with simple static arrays to save my data, etc, with the same results.

My major suspicion now is my lengthy source code. I've been working on this project (Intense X) for many many years now and I'm up to 1.5mb of code in 43 .c files. I've realized that if I comment out #includes of some .c files that contain functions that never even get executed on my test runs, the frequency of the E1513 crashes drop.

Finally, my attempts to debug the reported crashing functions using diag() gave me some pretty interesting results as well:

Let's say I get the following crash:



I fill the is_SubAction_CoverSpotsEvaluation function with diag()s to determine the exact position of the crash inside that function. I don't make any other changes in the code but the diag commands. I then run the project again, and it will now crash on a totally different function.

At one time I managed to get it to crash on the same function even after adding diags everywhere in it. This showed me that it's not unitialized variables that crash it since the function would run 10-20 times using a variable called xyz for example. The 21th time it run the function it would crash when it tried to access the variable xyz for the 21th time. Of course, if I add a few more diags I could move the crash to a whole different location.

I can't think of anything else I can do about this, so I'll have to give up on my project all together if you can't figure it out either. I could of course upload a level which always crashes at the beginning on my machine, although it could be about 100mb zipped.

I'm not sure if I'm still eligible for support or if I ever was (I got A7 Pro as a prize from last summer's Conitec contest) but I'm willing to pay anything it takes for you to take a look at the project. I get a nice return from it, especially on Christmas, and I wouldn't mind giving something back in order to keep it alive.

Thank you,
Aris

just a small tipp:
check if you have declared two different objects with the same name, like a function or a STRING* both having the same name
"void temp() {}" and "STRING* temp;"
The code will still compile fine then. That gave me random crashes all over my code (usually in plugin functions) and a week of debugging until i found the cause.

I had this error too at the weirdest places. It turned out I had some wrong initialized pointer and a missing allocation at a different place in the code.

Once I fixed this, the error was gone.
I guess in case of a pointer/address problem the message can say about everything, but th lsited function most likely is not the root of the problem.

Programmers encounter often this problem, and have to be creative for finding the reason - that's what makes programming so interesting. Sometimes more interesting than you'd prefer.

Typical reason for those symptoms is writing into a wrong memory area. Either it happens directly in your code, f.i. exceeding an array length or using invalid pointers. Or it's a damaged image, model, or sound file that you're loading. Wrong content of such a file causes memory areas to be overwritten by the loading functions of the DirectX or Windows API.

Both problems often don't crash immediately, but some time later when the overwritten memory area is accessed by a totally different function.

Try to find a code configuration where the crash always happens, or at least often. Then replace all loaded files step by step by a dummy file. This way you can find a file problem. If the crash then still happens, check all suspicious parts of your code.

Some common hints can also be found here: http://manual.3dgamestudio.net/debugging.htm

I get most of my crashes (~95%) by invalid pointers. Often it's either a ptr_remove to a pointer that was already removed or an access to a pointer that is already invalid (something like ent.string1).

Thank God GS prints out the function where the crash happens for some months ... earlier versions just printed out one of the functions that were currently running. So nowadays debugging is much easier.

Whereas I get most of mine from over-running the end of malloc'ed arrays.
Sometimes the invalid placed data gets put in a harmless variable,
or the data itself is harmless in the wrong variables....
Othertimes WHAMMO!!! Instant week-long headache.

But I gotta agree with JCL, this particulat type of fault can be a bugger to track down.
But thats OK, as I find that I improve 'dirty' coding-technique areas as part
of the bug hunt process...

@ Aris:
This may be hard with your code but you may try to tear your code apart bit by bit to locate the problem. Since i dont know your programming structure i cant tell if you can simply remove parts of your code backwards but this may help.
You may also try to find the code in older backups where it appeared. (Create backups before debugging like this but i guess you know that ^^ )

INTENSE X AI: STYROFOAM PACK

The latest Styrofoam pack enables you to play INTENSE X with the same capabilities as the others (wood, aluminum foil, bone), but now with random crashes! The errors arent Larry Laffer's fault, its conitec's fault! Lets move to another development engine!

@Grolflundren:
This isn't helpful. Please do not write posts like this.

@LarryLaffer:
I used to get these kinds of errors all the time in my early projects. Check to make sure you aren't overusing the wait() instruction. That sometimes causes it.

Larry
I posted this in the IX Beta forum also.
In a nutshell, we have 6 mini games pretty much ready to go using IX beta 1.0.5b and A7.80. None of them crash randomly!
Of corse we have a few bugs, but they are consistent and we have worked around them.

I notice the screenshot above is from standoff. When we tried standoff we got random errors also, Like JCL said could it be something bad in standoff!!! ie. Model, Image, Texture, wmb, dunno.

Do you get the random errors if you start a fresh project and work up from there?

Jethro.