Random E1513 Crashes

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.

LARRY, I've fixed Intense-x.

In a nutshell, make your NEXUS 400 for standoff, and no problems!

Like I said we have 6 games ready to go without the random crashes, So I looked into it further.

I loaded a fresh standoff from intense-x templates.
Ran the game and got random errors. Crash in "Is node total"
Crash in "Play actions", and the bad guys just stand there like dummies.

So I then re-built the backyard level as a Simple map A7.80. (Turned off radiosity and didn't create meshes)

Ran the game again, and now I get "Nexus to small". Upped the Nexus to 400 and no more problems.
The thing is with our projects we've been developing since day 1 on A7.50 - A7.80. And I guess we got the Nexus too small at some stage and upped it accordingly. So we don't have the random crashes.

I then made another new standoff project and run your supplied map with a nexus of 400 and it works also.

So your supplied backyard.wmb gives random crashes instead of nexus too small errors.
But works perfectly when you give it a 400 nexus.

JCL can you shine some light on this please. The manual states that A7 will alocate more memory when the nexus runs out.
Where is Aris's structs being created, in the games Nexus area or outside of this?

Jethro.

You can't "fix" a bug by just increasing the nexus.

When a bug occurs, you must locate it in the code or in the files, and fix it there. Also, you should not distribute a game with a nexus of 400. First find out what for you need that huge memory size. Even big commercial games should normally be well below 200 MB nexus, and if you need more, you should know why.

A7 does not always allocate more memory when the nexus runs out - this only goes up to a certain limit. You can see the memory situation in the F11 panel.

I did some tests, initially with intense-x the reason for the huge nexus is the models of the player and enemies, they have 1800 frames of animation. Could this be an A7 bug I remember there was a problem with bones recently found, causing large nexus requirements. Although these models have vertex animation, as soon as you add them to a project the nexus requirements go through the roof.

I'm only reporting what fixed the problem. I don't know if it's intense-x or A7's problem. But the problem with bones and models and nexus leads me possibly to think A7 also has issues with vertex animations and large amounts of animation frames.

Jethro.

A7 has no such "issues", but 1800 vertex frames explain the nexus problem. Normally you won't have models with 1800 vertex frames in a commercial game. You'd use bones animation.

But this is unrelated to the original problem, which was a random crash. 1800 vertex frames can make the game unplayable on low end machines, but won't cause random crashes. There's still a different reason.

- Nexus = 300 Random crash.
- Nexus = 400 Works perfectly.
- Rebuild map with A7.80.
- Nexus = 300 NEXUS TO SMALL error. Ah Ha.. no wonder we were getting random crashs.
Surely if the nexus is too small, but the engine doesn't pick this up, it will cause a random crash.
It's black and white to me.

There is nothing wrong with the code if the memory is available for it.
The original wmb somehow confused the engine, that there was enough nexus when in fact there wasn't so memory was being overwritten that shouldn't have been, thus causeing random crashes. (my theory)

I have an old P4 3.2 Gig Toshiba laptop with 1Gig of ram running XP about 5 years old. And the game runs fine with a nexus of 400 and yes 2 different models with about 1800 vertex frames each. One of them the enemy used many time throughout each level.
Give your engine more credit JCL, it doesn't struggle on this hardware, yet we consider it a minimum system these days.

Jethro.