Bad Alloc Crashes in 920 - Bad Timing

I just received a series of reports today that certain converted scenery will cause X-Plane to crash with a "bad alloc" error. Basically, this couldn't have hit us at a worse time. The final 920 was cut a week ago. We physically can't recut; Austin is on the road, and I am knee deep in it. But there is a possible work-around, and there will be a patch. Here's the whole situation.

What is a Bad Alloc?

A bad alloc error is an error that comes up when X-Plane runs out of memory. This can happen for two reasons:

• We have run out of address space - that is, there is no more virtual memory left, or
• We have run out of page file/physical memory - that is, we can't back that virtual memory.

The first case is by far the most common - you'd only hit the second if you are on Windows with a fixed-size (but small) page file. (Hint: if you have a fixed size page file, make it big!)

X-Plane can run out of memory for many reasons - everything that runs in the sim uses memory, and the amount used depends on what area you are in, what rendering settings you pick, and what third party add-ons you use. While I'd like to someday reach a point when the sim tells you gracefully that it's out of memory, it will always be a fact of life that at some point (hopefully an absurdly high one) the amount of stuff you've asked X-Plane to do will exceed how much memory you have.

(If you are thinking 64 bits, well, that will just change the problem from a crash to a grinding halt when we run out of physical memory.)

We see bad allocs when there are too many third party add-ons installed (XSquawkBox is a particular pig because it loads every CSL on startup), too complex scenery, and it can also be caused by drivers not efficiently using memory. (This is particularly a problem on Vista RTM.)

The Bug

When X-Plane creates a curved airport taxiway, it allocates a temporary memory buffer to hold the intermediate product of the pavement. The size of that buffer depends on the complexity of the curve it is processing and a constant, based on the maximum curve smoothness.

In 920 I provided an option to crank up the curve smoothness in X-Plane. In the process, I increased that constant factor by 4x, which causes X-Plane to hit its memory ceiling on layouts that used to be acceptable. You'll see this problem more often on:

• Bigger, more complex layouts.
• Configurations that were already chewing up a lot of memory.
• Machines with less address space (Windows without /3GB, older Mac OS X operating systems.)

What really suckered us about this bug was that it comes in a form that looks almost the same as a driver issue we've seen with ATI drivers on Windows -- we've seen strange forms of memory exhaustion on ATI when shifting scenery with high rendering settings. So we didn't realize that this was something new until G5 users reported the bug (making us realize it wasn't a driver thing).

What To Do

The bad news is that we can't do an RC5 - we're out of time. But - there will be a patch - relatively soon. This bug is on the short list for a patch to fix 920.

In the meantime, there is actually a work-around. By coincidence, some of the internal rendering engine constants are viewable via the "private dataref" system -- basically a series of datarefs in the sim/private/... domain that I use for on-the-fly debugging. The dataref that matters here is:

sim/private/airport/recurse_depth

If you load up DataRef Editor you'll see it has a value of 12 . That's too high. Changing it to 10 will allow otherwise problematic airports to load.

I will try to post a plugin in the next 10 days that sets this dataref to 10 on startup, effectively patching the problem. This will also limit the maximum smoothness of curves - but my guess is that if you see the crash (not all users do) then you can't run on the max airport curve setting anyway.

Of course the next patch will contain a real solution: a more efficient memory allocation scheme!