Anarchies 1.0 crashing Oolite 1.70 on a mac

For test results, bug reports, announcements of new builds etc.

Moderators: winston, another_commander, Getafix

Post Reply
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Anarchies 1.0 crashing Oolite 1.70 on a mac

Post by Eric Walch »

I just witnessed re-produceble Oolite crashes to desktop with "anarchies.oxp 1.0". I can't find what is causing it. I assume is is triggered by an other bug in oolite itself.

The bug happens with my latest save file. When I open this, Oolite crashes with following mac-crashreport:

Code: Select all

Thread 0 Crashed:
0   libSystem.B.dylib              	0x900031c8 strlen + 8
1   com.apple.Foundation           	0x92bcd030 +[NSString stringWithUTF8String:] + 36
2   org.aegidian.oolite            	0x00047b38 AbbreviatedFileName + 128 (crt.c:355)
3   org.aegidian.oolite            	0x00047e94 OOLogWithFunctionFileAndLineAndArguments + 192 (crt.c:355)
4   org.aegidian.oolite            	0x00048108 OOLogWithFunctionFileAndLine + 40 (crt.c:355)
5   com.apple.Foundation           	0x92bf12a8 NSLogv + 188
6   com.apple.Foundation           	0x92bf11dc NSLog + 28
7   com.apple.Foundation           	0x92cb35e4 -[NSObject doesNotRecognizeSelector:] + 60
8   com.apple.Foundation           	0x92bd9e78 -[NSObject(NSForwardInvocation) forward::] + 176
9   libobjc.A.dylib                	0x90a460b0 _objc_msgForward + 176
10  org.aegidian.oolite            	0x0002e538 -[Universe setUpSpace] + 2168 (crt.c:355)
11  org.aegidian.oolite            	0x0006e52c -[PlayerEntity(LoadSave) loadPlayerFromFile:] + 532 (crt.c:355)
12  org.aegidian.oolite            	0x000ae444 -[PlayerEntity(OOControlsPrivate) pollDemoControls:] + 272 (crt.c:355)
13  org.aegidian.oolite            	0x000ae2d0 -[PlayerEntity(Controls) pollControls:] + 224 (crt.c:355)
Removing Anarchies.oxp solved the problem thus this one was involved. Then I disabled the inside script: Crashes still happened. Crashes stopped when I disabled the "shipData.plist". On this one I looked closer. Deleting the first 20 entries also solved the crash. Only deleting the first ten or second ten entries still crashed Oolite. Very strange but reproducible with this savefile.

Looking at the first 20 entries, they all have a role starting with "anarchie-". And because the script was still disabled, none of these ships should have been used by anarchies. But I know that 1.70 has a bug that is sometimes selects wrong ships. So for some reason with this save file the dices roll in a way that it was selecting something from anarchies that bugged. Maybe a part of a bigger structure that works well when chosen in the right way.

Anyhow, one of the last entrys in the crashlog is: [Universe setUpSpace] and I think that it goes wrong there on setting up space. Also meaning that this bug could happen with other players when jumping to an other system.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

I’m not able to recreate this with a clean 1.70, Anarchies 1.0 and all log messages enabled, but I did find a freezing bug in addEntity:.

Then I looked at the crash log again and realized immediately what the problem was.

Fixed for next release; in the meantime, the workaround is to disable logging-show-file-and-line:

Code: Select all

defaults write org.aegidian.oolite logging-show-file-and-line -bool no
This shouldn’t affect many people, since it’s off by default. This won’t fix whatever the root problem is, but it’ll stop the game from crashing in the way it’s doing for you.
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

Ahruman wrote:
I’m not able to recreate this with a clean 1.70, Anarchies 1.0 and all log messages enabled, but I did find a freezing bug in addEntity:.
I'm sure it is difficult to reproduce as it happened me only while loading a certain save file, not with the others. (I made a mistake that I have that file now overwritten.) It could be that the problem is solved in the trunk. What I am currently witnessing are that regularly large asteroids being added when a ship crashes. It are the large ones from asteroid storm. It happens when I instal Random Hits, but it also happens when I instal Anarchies. frightening when you kill a small mamba and then you crash into several very large asteroids. Somehow these two oxp's force that more ships with a wrong role are selected that normally. Or it is more visible because of the size.
User avatar
LittleBear
---- E L I T E ----
---- E L I T E ----
Posts: 2876
Joined: Tue Apr 04, 2006 7:02 pm
Location: On a survey mission for GalCop. Ship: Cobra Corvette: Hidden Dragon Rated: Deadly.

Post by LittleBear »

Thats really strange! I do add ships with the role asteroid near the bars, and there is a small random chance of a bunch of Thargoids attacking a bar. In both cases I'm just adding them with addShips and using the standard Oolite role. Everything else has a custom role starting with random_hits. Any idea how it could cause it? I haven't had it happen on 1.70 Windows XP.
OXPS : The Assassins Guild, Asteroid Storm, The Bank of the Black Monks, Random Hits, The Galactic Almanac, Renegade Pirates can be downloaded from the Elite Wiki here.
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

LittleBear wrote:
Thats really strange! I do add ships with the role asteroid near the bars,.... I haven't had it happen on 1.70 Windows XP.
I don't think the fault is inside Random Hits because I shoot a non-randomhits ship and the asteroids are part of Asteroid storm. The ship should create wreckage, metal plating, but for some reason it choses rocks. Without random hits and with Anarchies I see the same. Without those two no problems. But there are still other occasions of ships that are selected in the wrong role.

I just had an other re-producible crash to the desktop. This time on hyperspace jumping to a certain system. On removing Anarchies the problem was over. I think it is something similar. Not something in the OXP. but it makes that the system adds a object from an other oxp that is buggy.

--
I must say that this were some of the few occasions I had crashes to the desktop. Normally 1.70 runs very stable for me.
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Knowing which system would help. Or having a saved game.

Remember, every crash, even if it can be tied to a specific OXP, is a serious bug in the game.
User avatar
Commander McLane
---- E L I T E ----
---- E L I T E ----
Posts: 9520
Joined: Thu Dec 14, 2006 9:08 am
Location: a Hacker Outpost in a moderately remote area
Contact:

Post by Commander McLane »

@ Eric: Sorry for the trouble! Unfortunately I have also no idea what is going on, and crash reports generally are just greek for me (no, not true, as I actually can read greek).

But what I forgot in my PM: Could you just send me your save-file, so that I can try it on my machine?

commander_mclane squiggle planet point ms

Thanks!
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

After a little playing with the crash I found that when I removed one of the next 3 oxp's the crash stopped: Anarchies1.0, AsteroidStorm 3.45 or Hotrods 0.51 I turned on all logging options and noticed the last few entries in the log had to do with the ship: "hood-spittingcobra-2" from Hotrods. When I change its role so it was not selected, the crash stopped. Removing of the other two oxp probably only changed the dices so this ship was not added?

The last entries in the log were:

Code: Select all

===== zaterdag 15 maart 2008 13:55:02 uur Europe/Amsterdam =====
..
Oolite [dataCache.retrieve.success] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:161): Retrieved "OOSelfDrawingEntity-mesh" cache object icosahedron.dat.
Oolite [dataCache.retrieve.success] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:161): Retrieved "dictionaries" cache object AIs/pirateAI.plist merge:none.
Oolite [dataCache.retrieve.failed] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:165): Failed to retrive "OOMesh" cache object hood_spittingcobra4.dat -- no such entry.
Oolite [dataCache.retrieve.failed] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:165): Failed to retrive "resolved paths" cache object Models/hood_spittingcobra4.dat -- no such entry.
Oolite [dataCache.set.success] -[OOCacheManager setObject:forKey:inCache:] (OOCacheManager.m:202): Updated entry Models/hood_spittingcobra4.dat in cache "resolved paths".
Oolite [dataCache.set.success] -[OOCacheManager setObject:forKey:inCache:] (OOCacheManager.m:202): Updated entry hood_spittingcobra4.dat in cache "OOMesh".
Oolite [dataCache.retrieve.failed] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:165): Failed to retrive "resolved paths" cache object Textures/Hood4.png -- no such entry.
Oolite [dataCache.set.success] -[OOCacheManager setObject:forKey:inCache:] (OOCacheManager.m:202): Updated entry Textures/Hood4.png in cache "resolved paths".
Oolite [dataCache.retrieve.failed] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:165): Failed to retrive "octrees" cache object hood_spittingcobra4.dat -- no such entry.
Oolite [dataCache.set.success] -[OOCacheManager setObject:forKey:inCache:] (OOCacheManager.m:202): Updated entry hood_spittingcobra4.dat in cache "octrees".
Oolite [dataCache.retrieve.success] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:161): Retrieved "resolved paths" cache object Scripts/oolite-default-ship-script.js.
Oolite [dataCache.retrieve.success] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:161): Retrieved "compiled JavaScript scripts" cache object /Applications/Games/Oolite/Oolite1.70.app/Contents/Resources/Scripts/oolite-default-ship-script.js.
Oolite [dataCache.retrieve.success] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:161): Retrieved "dictionaries" cache object Config/autoAImap.plist merge:basic.
Oolite [textureLoader.asyncLoad] -[OOTextureLoader(OOTextureLoadingThread) performLoad] (OOTextureLoader.m:308): Loading texture Hood4.png
Oolite [textureLoader.asyncLoad.done] -[OOTextureLoader(OOTextureLoadingThread) performLoad] (OOTextureLoader.m:313): Loading complete.
<no entries after this one>
He fails to find <hood_spittingcobra4.dat > but that thing is present in the file. Maybe there is more to the bug. It takes its role over a like_ship, but when I explicit gave it his roles the scrash still happens. When I gave that ship also a special role and add it with that role, everything is fine:

Code: Select all

Oolite [dataCache.retrieve.success] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:161): Retrieved "OOMesh" cache object hood_spittingcobra4.dat.
Oolite [dataCache.retrieve.success] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:161): Retrieved "octrees" cache object hood_spittingcobra4.dat.
Oolite [dataCache.retrieve.success] -[OOCacheManager objectForKey:inCache:] (OOCacheManager.m:161): Retrieved "resolved paths" cache object Scripts/oolite-default-ship-script.js.
User avatar
Kaks
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 3009
Joined: Mon Jan 21, 2008 11:41 pm
Location: The Big Smoke

Post by Kaks »

I'll see if I can replicate the problem on my pc. Will let you know asap!
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
User avatar
Eric Walch
Slightly Grand Rear Admiral
Slightly Grand Rear Admiral
Posts: 5536
Joined: Sat Jun 16, 2007 3:48 pm
Location: Netherlands

Post by Eric Walch »

Ahruman wrote:
I’m not able to recreate this with a clean 1.70, Anarchies 1.0 and all log messages enabled, but I did find a freezing bug in addEntity:.

Then I looked at the crash log again and realized immediately what the problem was.

Fixed for next release; in the meantime, the workaround is to disable logging-show-file-and-line:

Code: Select all

defaults write org.aegidian.oolite logging-show-file-and-line -bool no
This shouldn’t affect many people, since it’s off by default. This won’t fix whatever the root problem is, but it’ll stop the game from crashing in the way it’s doing for you.
Thanks. That did the trick. I looked back in my crashlog and noticed a lot of crashes ended with the lines logging-show-file-and-line. I understand it right that it found a bug and that crashed on logging it?
User avatar
JensAyton
Grand Admiral Emeritus
Grand Admiral Emeritus
Posts: 6657
Joined: Sat Apr 02, 2005 2:43 pm
Location: Sweden
Contact:

Post by JensAyton »

Eric Walch wrote:
He fails to find <hood_spittingcobra4.dat > but that thing is present in the file.
The “Failed to retrive…” [sic] lines just mean something isn’t in the cache, not that it can’t be found at all.
Eric Walch wrote:
Thanks. That did the trick. I looked back in my crashlog and noticed a lot of crashes ended with the lines logging-show-file-and-line. I understand it right that it found a bug and that crashed on logging it?
The problem was that the a function involved in dealing with file names in logs wasn’t dealing properly with NULL file names, which occur for instance when an NSLog is intercepted (OS X only).
Post Reply