Oolite v1.82, OSX Yosemite 10.10.4 - Game fails to load?

[ffutures]

Here:

https://dl.dropboxusercontent.com/u/472 ... evious.log

[ffutures]

One thing I notice from the log is that there seems to be a lot of stuff loading which I downloaded for previous versions but haven't re-installed for 1.82 - I deleted Oolite iteself before reinstalling but there must be a lot of files in the library and/or application support that don't go with it. Could the problem be there?

[cim]

Could the problem be there?

Shouldn't be - the OXZs will just not load if they're not compatible with 1.82, and a 1.80 cache file will have been rebuilt too.

Nothing in the log - apart from it failing to load - looks out of the ordinary. Especially odd is that it doesn't always fail... is there any pattern to that (e.g. if it loads the first time it'll keep working so long as you don't close Oolite?)

[ffutures]

Not that I've been able to determine - it's pretty random, apart from consistently not loading that particular saved game.

[zevans]

Hello. I'm back after quiiiiiiiite a long time, and I've binned the netbook - here I am on a Mac thread.

1.82 looks beautiful - but same problem. Start, play, save game at Zaonce, can't reload it. The only difference is it's consistent for me. It didn't work under 10.10.3 either...

Code: Select all

22:34:47.456 [load.progress]: Creating player ship
22:34:47.456 [load.progress]: Initialising player entity
22:34:48.624 [script.load.world.listAll]: Loaded 31 world scripts:
    behemoth 3.1
    Comms Pack A 0.5
    military_fiasco 2.5.3
    Oolite Equipment Control 1.82
    Oolite Ship Library 1.82
    oolite-cloaking-device 1.82
    oolite-constrictor-hunt 1.82
    oolite-contracts-cargo 1.82
    oolite-contracts-helpers 1.82
    oolite-contracts-parcels 1.82
    oolite-contracts-passengers 1.82
    oolite-libPriorityAI 1.82
    oolite-nova 1.3.0
    oolite-populator 1.82
    oolite-primable-equipment-register 1.82
    oolite-registership 1.82
    oolite-thargoid-plans 1.82
    oolite-trumbles 1.3.0
    oolite-tutorial 1.82
    Pi-Forty-Two Con stores 4.2.2
    randomshipnames 1.6
    System Features: Rings 1.2
    ups_container 1.8.4
    ups_docs 1.8.4
    ups_parcel 1.8.4
    ups_slaves 1.8.3
    ups_sun 1.8.4
    Xenon UI Resource Pack D (16:10) 1.0.0
    XenonHUD 1.1.1
    XenonUI 1.3.0
    YAH_mobile_populator 1.0
22:34:48.679 [load.progress]: Loading commander data
22:34:48.789 [load.progress]: Recording save path
22:34:48.789 [load.progress]: Creating system
22:34:49.235 [load.progress]: Resetting player flight variables
22:34:49.236 [load.progress]: Loading system market
22:34:49.236 [load.progress]: Setting scenario key
22:34:49.236 [load.progress]: Starting JS engine

and then it stops. Which other logging should I change to "yes" in logcontrol.plist to find out what's going on?

[cim]

It does fit with the other logs that the problem is in JS engine initialisation. Or possibly it's in JS engine reinitialisation, since it lets you start a game ... if you use the "-load" command-line parameter to immediately load a save game on startup, does it let you load the game?

[zevans]

Code: Select all

open "Oolite.app" --args -load ~/Documents/Evans.oolite-save

Assuming I am doing this right... then it starts Oolite OK but the saved game isn't actually loaded.

[Eric Walch]

I just noticed this bugreport. I can't reproduce it either with OSX 10.10.4. I tried both the 1.82 deployment version as the developpers version.

Probably ffutures should download the developpers version. It is also on the http://oolite.org/download/ page but a little bit down on the page. The difference is that it has more logging.

The fastest way to access the latest log from within the game is going to the Oolite menu with the 'option-key' pressed. The option to access the previous log changes to the "log folder".

And in the development version it is just typing ⌘L to access the current log.

[zevans]

Just downloaded last night's Dev version and... same problem. So now I can get into tracking it down...

[zevans]

I changed pretty much everything in logcontrol.plist to "yes".

The final message in the log when I try and load the saved file is...

Code: Select all

16:38:02.317 [load.progress]: Loading system market

By this point I can see it has generated the sky and loaded the Station AI and so on, so it's a complete mystery. Is there any other debugging I can turn on?

[zevans]

Oh great. It's a Heisenbug. It worked once yesterday!

I had a look at the source - noticed after it has generated the market, it calls something to do with cargo and I seem to remember there's been a couple of weird problems with that, so I'm now breeding two tribbles and making five...

[zevans]

OK, after some breakpoint fun I have tracked this down to an EXC_BAD_ACCESS in ooConcreteTexture.m - which would explain why just occasionally it works at a functional level but some of the 2D textures are trashed, and quite often it crashes completely.

Line 568 is where the crash happens, although obviously it might be caused by something much earlier in the flow.

I have XenonUI installed which exercises the 2D textures quite a lot - but even if the OXP is doing something wrong it shouldn't trigger a CTD should it?

[cim]

OK, after some breakpoint fun I have tracked this down to an EXC_BAD_ACCESS in ooConcreteTexture.m - which would explain why just occasionally it works at a functional level but some of the 2D textures are trashed, and quite often it crashes completely.

Since it's non-deterministic where it occurs, I wonder if the problem is just running out of memory - but that seems implausible unless your system is very short on free memory.

[zevans]

OK, after some breakpoint fun I have tracked this down to an EXC_BAD_ACCESS in ooConcreteTexture.m - which would explain why just occasionally it works at a functional level but some of the 2D textures are trashed, and quite often it crashes completely.

Since it's non-deterministic where it occurs, I wonder if the problem is just running out of memory - but that seems implausible unless your system is very short on free memory.

I wondered that. However it still does it with a release binary (no debug cruft), on a system where I have killed everything else I can think of first, and purged before running. It's using about 200 MB when it falls over. When it works it uses way more than that. So it can't be a general memory constraint.

HOWEVER I think MacOS has quite a history of weird constraints in the graphics driver itself - maybe we've hit one of those? I suppose I could try halving the size of all the textures and see what happens...

When I have some proper time I'll see if I can do anything with the memory profiling stuff in Xcode.

I also wondered if there was something (accidentally) unique in what XenonUI is doing, and we're tripping over some code path or edge case that's not normally used.

[cim]

HOWEVER I think MacOS has quite a history of weird constraints in the graphics driver itself - maybe we've hit one of those? I suppose I could try halving the size of all the textures and see what happens...

If that's it, then the max-texture-size setting would be an easy way to test it - http://wiki.alioth.net/index.php/Hidden ... e#Graphics

It's possible that XenonUI's extensive set of 2048x1024 textures is overloading something.

If you do an OOLog(@"debug",@"%@",[self name]); at the top of the function which crashes, you might get an idea of which files are causing it.