Windows Trunk version 1.77.0.5057 experiencing CTD!

[Svengali]

Together with the “rainbow dust” bug reported upthread, it looks like the dust entity’s data is getting corrupted. Or maybe it isn’t responding to graphics resets? Gives me somewhere to dig, anyway.

After updating to r5358 I have no CTDs anymore and dust looks ...erm... dusty. Muchas gracias .-)

[JensAyton]

After updating to r5358 I have no CTDs anymore and dust looks ...erm... dusty. Muchas gracias .-)

Pah! What part of “no fix yet” don’t you understand?

Seriously, I’m pretty sure nothing has changed WRT this bug since r5352. You’ve just been lucky so far.

[Tricky]

Does this mean no more magic pixie dust?

[cim]

The CTDs on my Windows system predate the rainbow dust's appearance by at least 50 revisions. Once the dust changes the crashes get much easier to trigger, but there was a problem before then too.

So I suspect some subtle bug, which around r5200-5230 started infecting the dust shader. Possibly around r5358 things have changed again so it doesn't infect the dust shader, or possibly you just need to give it time or face a different direction...

[Kaks]

FWIW, I still get multicoloured dust particles with the latest trunk, so I'm predicting some more bugfixing in that area... as the big A rightly said already

[Wildeblood]

I actually like the rainbow dust, so I'm hoping it turns out to be harmless and unrelated to the CTDs.

[cim]

Okay, got as far back as r5143 last night, and it still crashes pretty reliably if you're on injectors, pitching full, and exploding at the same time.

[Cody]

Okay, got as far back as r5143 last night

Crikey... when would that be, date-wise?

... it still crashes pretty reliably if you're on injectors, pitching full, and exploding at the same time.

I'll remember that combination for future testing... exploding in those circumstances is not something I make a habit of.

[cim]

29 July, according to the logs. That was the earliest one I tried on the basis of your "somewhat before the trial 1.76.1 deployment build" guess, but possibly earlier.

Once the multi-coloured dust appears somewhere between 5230 and 5287, the crashes get much easier to trigger accidentally and in routine flight.

I might drop right back to 4680ish next just to confirm that these crashes are in fact from after the 1.76 release. If it's a bug from back that far (which Switeck's experience suggests), it really could be anywhere.

[cim]

Hmm. One extra datapoint before I reboot into Windows to try that - I decided to try the same high-pitch, high-speed explosions on Linux, with a new Jameson plus injectors.

Most of the time, nothing unusual happened. However, just once - out of about twenty attempts:

Code: Select all

Exception: Error: Native exception: NSDecrementExtraRefCount() decremented too far
    oolite-debug-console.js, line 844:
    	}

on the console and

Code: Select all

17:24:33.933 [script.javaScript.exception.ooliteDefinedError]: ***** JavaScript exception (<unidentified script>): Error: Native exception: NSDecrementExtraRefCount() decremented too far

in Latest.log

...which implies that something is getting released once more than it gets retained. That means that something is trying to access it thinking it's a live reference when it's not, which with slightly different timing could cause a segfault - and the windows threading model is different enough that that could explain things.

[JensAyton]

Try to repeat it with the environment variable NSZombieEnabled set to YES. This will tell us the class of the overreleased object. (Side effect: memory usage will be rather high since all objects will effectively be leaked.)

[cim]

Well, I'm back from the land of Windows with the cause of the rainbow dust and the crashes (which are completely linked)

Here's the "cause": OOPlanetEntity.m (yes, r4843...)

Apparently, not drawing the planet causes serious problems. Having figured that out, I can duplicate the problem on Linux, too, though it doesn't cause an actual crash there.

Possibly a more useful exception:

Code: Select all

20:56:44.509 [exception]: ***** Exception during [manageCollisions] in -[PlayerEntity update:] : NSInternalInconsistencyException : NSDecrementExtraRefCount() decremented too far *****
20:56:44.509 [exception]: ***** Exception during [update:entity [<PlayerEntity 0x7fa8e59a0560>{"Cobra Mark III" position: (-49499.6, 60434.3, 427232) scanClass: CLASS_PLAYER status: STATUS_DEAD}]] in [Universe update:] : NSInternalInconsistencyException : NSDecrementExtraRefCount() decremented too far *****

Setting the environment variable didn't appear to say the class of the object anywhere, though it did cause excessive memory usage.

Anyway, I've no idea what's going on here, but r5364 should stabilise trunk for the immediate future while that gets figured out.

[Eric Walch]

In trying to explode at injectors while pitching full, I failed to CTD. No idea if I 'exploded' correctly. I tried PS.explode() in the console a few times. And a dozen of times by crashing into the main station. No result other than normal death.

Only one hour later when returning to the computer, I found in the log:

Code: Select all

[exception]: ***** Exception during [update:entity [<ShipEntity 0x13fa39e00>{"Thargoid Thargorn Battleship" position: (-374.204, -4249.64, 232412) scanClass: CLASS_THARGOID status: STATUS_IN_FLIGHT}]] in [Universe update:] : NSGenericException : *** Collection <NSCFSet: 0x11bf7aff0> was mutated while being enumerated.<CFBasicHash 0x11bf7aff0 [0x7fff70131ee0]>{type = mutable set, count = 4,
entries =>
	0 : <ShipEntity 0x101ea8c00>{"Cargo Pod" position: (357.974, 2880.74, 232791) scanClass: CLASS_CARGO status: STATUS_IN_FLIGHT}
	2 : <ShipEntity 0x1234ff800>{"Metal fragment" position: (2238.22, 3780.84, 240660) scanClass: CLASS_CARGO status: STATUS_IN_FLIGHT}
	5 : <ShipEntity 0x136cf0200>{"Trident Privateer Mark I" position: (-101.678, -10592, 227269) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}
	6 : <ShipEntity 0x101bc9a00>{"Cargo Pod" position: (16479, 1866.74, 229061) scanClass: CLASS_CARGO status: STATUS_IN_FLIGHT}
}
 *****
[exception]: ***** Exception during [update:entity [<ShipEntity 0x13f80ee00>{"Terroriser Frigate" position: (-3531.41, 119.717, 216947) scanClass: CLASS_THARGOID status: STATUS_IN_FLIGHT}]] in [Universe update:] : NSGenericException : *** Collection <NSCFSet: 0x11db44010> was mutated while being enumerated.<CFBasicHash 0x11db44010 [0x7fff70131ee0]>{type = mutable set, count = 1,
entries =>
	2 : <ShipEntity 0x123258000>{"Missile" position: (-386.591, -1374.09, 230199) scanClass: CLASS_MISSILE status: STATUS_IN_FLIGHT}
}
 *****
[exception]: ***** Exception during [update:entity [<ShipEntity 0x13fa39e00>{"Thargoid Thargorn Battleship" position: (-1457.75, -4890.98, 255827) scanClass: CLASS_THARGOID status: STATUS_IN_FLIGHT}]] in [Universe update:] : NSGenericException : *** Collection <NSCFSet: 0x11bf7aff0> was mutated while being enumerated.<CFBasicHash 0x11bf7aff0 [0x7fff70131ee0]>{type = mutable set, count = 3,
entries =>
	2 : <ShipEntity 0x1234ff800>{"Metal fragment" position: (584.103, 2976.45, 239423) scanClass: CLASS_CARGO status: STATUS_IN_FLIGHT}
	5 : <ShipEntity 0x123050600>{"Imperial Courier" position: (4964.42, -4614.83, 264921) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}
	6 : <ShipEntity 0x13fc90e00>{"Military Manta Ray" position: (-10861, -8665.89, 256256) scanClass: CLASS_POLICE status: STATUS_IN_FLIGHT}
}
 *****
[exception]: ***** Exception during [update:entity [<ShipEntity 0x13fa39e00>{"Thargoid Thargorn Battleship" position: (3560.1, -5893.58, 263206) scanClass: CLASS_THARGOID status: STATUS_IN_FLIGHT}]] in [Universe update:] : NSGenericException : *** Collection <NSCFSet: 0x11b8aa1b0> was mutated while being enumerated.<CFBasicHash 0x11b8aa1b0 [0x7fff70131ee0]>{type = mutable set, count = 1,
entries =>
	1 : <ShipEntity 0x13fc90e00>{"Military Manta Ray" position: (-17443.1, -13197.1, 257358) scanClass: CLASS_POLICE status: STATUS_IN_FLIGHT}
}
 *****

Player was docked all the time. Very likely unrelated.

[JensAyton]

Here’s some debugging magic that actually works:

Code: Select all

if (gDebugFlags & DEBUG_MISC)
{
    gDebugFlags &= ~DEBUG_MISC;
    LogOpenGLState();
}

I put it before both glEnableClientStates in DustEntity.m and triggered it from the console with console.debugFlags = console.DEBUG_MISC. (Note: there was a similar thing in OOPlanetDrawable using the same flag, which I removed. With both in place, only the planet one would fire.)

In “rainbow mode”, the flag GL_COLOR_ARRAY is active because the sky drawable wasn’t resetting it properly. This shouldn’t cause a crash, though, at least in Lave, because the colour array left in effect has 692 entries (for 173 nebulas) and there are 600 dust particles.

In any case, I’ve fixed the colour glitch in r5366, but left planet culling off so we hopefully get one stableish Windows nightly.

I suspect the overrelease issue isn’t directly related. I don’t know why zombies aren’t reporting in GNUstep, possibly the thing that’s throwing an exception instead of crashing is getting in the way.

[Cody]

... we hopefully get one stableish Windows nightly.

Cool... I'll grab that first thing in the morning. Thanks!