Windows Trunk version 1.77.0.5057 experiencing CTD!

[Switeck]

I'll try to get trunk to run again this evening - earlier, I launched into a convoy, and targetted each ship in turn, re-arming the missile each time. All the blips continued to flash, even after I'd un-targetted them. I'll re-download TAP and install a vanilla version, in case I've tinkered with the one I'm using (I don't recall tinkering, but...).

I'm on Win XP, btw.

I typically got the HUD flashing (especially noticeable on the missiles) after doing a cloaked misjump. It tended to get worse right before a CTD. On Win XP as well.

Latest trunk build (5279) I ran flashed less during cloaked misjumps and crashed less often when using a Boa 2 but my stupid-fast hacked Constrictor still tended to crash before I'd done 4 cloaked misjumps.

[Kaks]

Do let me know if there are any differences in the way the hud is displayed between 1.76.1 and trunk, I'm planning a bit more code tweaking there, and the sooner any wrongness is spotted, the easier to correct it!

[Cody]

Update: v1.77.0.5335 (with OXPs installed) ran for twenty minutes, then crashed. There is an error (same time as the crash) in the log though:

Code: Select all

16:11:08.921 [exception]: ***** Exception during [update:entity [<ShipEntity 0x1a644508>{"Mamba" position: (-3440.93, -13505.8, 454781) scanClass: CLASS_NEUTRAL status: STATUS_IN_FLIGHT}]] in [Universe update:] : NSInvalidArgumentException : Tried to add nil value for key 'primaryTarget' to dictionary *****

First error message I've seen... any use? Or a red herring?

[cim]

No red herring - and I think that one should be fixed in r5337 - but probably entirely unrelated to the other crashes you've been having.

I'll go and test trunk on Windows XP now.

[Wildeblood]

For me trunk seems to crash as soon as any player ship performance parameter reaches its maximum. Launch, yaw sharply to turn away from the station, as soon as yaw = maxYaw, CTD. Game over in 5 seconds. Tonight I targeted a wormhole, saw it was collapsing very soon, pressed I for injectors, instant CTD. Was that a problem with using injectors specifically, or just that speed reached maxSpeed?

[cim]

Well, good news: my Windows XP build of Oolite crashes all over the place. More recent revisions seem a lot more unstable (and Wildeblood's trick seems to trigger crashes reasonably consistently around r5230 or later) but so far I've got back to r5195 and things are still a bit unstable: most commonly crashing on player death.

r5177 seemed okay at first glance, but it took a few attempts to get r5195 to crash, so that's not entirely convincing me yet. I'll test more tonight.

I suspect something is up in the graphics code, though it must be fairly subtle since on Linux trunk has been almost completely stable for months.

[Wildeblood]

Do let me know if there are any differences in the way the hud is displayed between 1.76.1 and trunk, I'm planning a bit more code tweaking there, and the sooner any wrongness is spotted, the easier to correct it!

This afternoon I opened up HeadUpDisplay.m to add a draw_surround key to the four dials that didn't have it - drawFuelBar:, drawCabinTempBar:, drawWeaponTempBar: & drawAltitudeBar: - and what do I find? It's already been done in trunk. I'm sure it wasn't so the last time I looked. So, hmm, thank you.

But, what's this? Why give three of the four green surrounds, but the altitude bar a yellow surround? I swear sometimes you do these things just to irritate me. Or maybe you just want to see whether anyone actually notices?

[Cody]

Well, good news: my Windows XP build of Oolite crashes all over the place.

Phew... thanks for that, cim. I was beginning to wonder, what with my gfx card now giving me problems too.

[Switeck]

For me trunk seems to crash as soon as any player ship performance parameter reaches its maximum. Launch, yaw sharply to turn away from the station, as soon as yaw = maxYaw, CTD. Game over in 5 seconds. Tonight I targeted a wormhole, saw it was collapsing very soon, pressed I for injectors, instant CTD. Was that a problem with using injectors specifically, or just that speed reached maxSpeed?

That happens to me even on v1.76.1 -- I can launch from station, cloak (since my bounty may just happen to be...high...and I don't want the police jumping on me), pull up, and inject away from the station. Roughly the moment I hit max pitch (like I'm trying to force a misjump)...I sometimes get a CTD.

Win XP Pro SP3, 4 GB ram, Geforce GTS 250 video card.

Code: Select all

16:19:12.531 [display.mode.list.native]: Windows native resolution detected: 1280 x 720
16:19:12.718 [joystick.init]: Number of joysticks detected: 0
16:19:12.734 [dataCache.notFound]: No data cache found, starting from scratch.
16:19:12.750 [rendering.opengl.version]: OpenGL renderer version: 3.3.0 ("3.3.0"). Vendor: "NVIDIA Corporation". Renderer: "GeForce GTS 250/PCIe/SSE2".

[cim]

Okay, I've got as far back as r5170 and it's still crashing now and then. That would be the start of August, or thereabouts.

r5159 crashed too, but in a different way. That may have been the bug fixed in r5165, though.
None of r5143, r5144, and r5151 crashed in extended play, and are probably clean (or, at least, only offenders for Switeck's long standing crashes).

Busy this weekend, so searching will continue on Monday...

[Kaks]

But, what's this? Why give three of the four green surrounds, but the altitude bar a yellow surround? I swear sometimes you do these things just to irritate me. Or maybe you just want to see whether anyone actually notices?

Sometimes?

And it is nice when someone notices, thank you!

On a slightly more serious note, the original intention was to end up with the default surrond colour being the same they have in the standard HUD: shields => green, but fuel, altitude, laser & cabin temperature yellow, Half way through, I did think it would make more sense if all the surronds were to use the same default, and I clearly didn't spot the altitude surround defaulting to yellow.

All the pre-existing 'dial' features should hopefully still be the same though, at least for the time being...

[Svengali]

After a return orgy in r5352 the backtrace showed something (a part of my NVidia driver)...

Code: Select all

#0  0x698063be in nvoglnt!DllMain () from C:\WINDOWS\system32\nvoglnt.dll

...and a whole while later 'returning'

Code: Select all

#0  0x0041734a in -[DustEntity drawEntity::] (self=)
    at src/Core/Entities/DustEntity.m:347
347                     OOGL(glDrawArrays(GL_POINTS, 0, DUST_N_PARTICLES));
Current language:  auto; currently objective-c
(gdb) Cannot access memory at address 0xc427c008

Another attempt showed a bit more

Code: Select all

#0  0x0041734a in -[DustEntity drawEntity::] (self=0x0, _cmd=0x0, 
    immediate=136 '\210', translucent=136 '\210')
    at src/Core/Entities/DustEntity.m:347
347                     OOGL(glDrawArrays(GL_POINTS, 0, DUST_N_PARTICLES));

[JensAyton]

Code: Select all

    at src/Core/Entities/DustEntity.m:347
347                     OOGL(glDrawArrays(GL_POINTS, 0, DUST_N_PARTICLES));

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.

[JensAyton]

No fix yet, but a possible workaround is an OXP that disables dust rendering.

Dust killer.oxp

It requires Debug.oxp. It may or may not require an active console connection; it should work without, but I’m not at all sure that feature actually works (except on Macs).

[Kaks]

I can confirm it removes dust from windows ( nvidia drivers ) too, without a connected debug console.