Crashes with 1.72 on mac

[Eric Walch]

Oolite just crashed the third time. All crash logs are identical:

Code: Select all

Date/Time:      2008-11-03 23:15:47.272 +0100
OS Version:     10.4.11 (Build 8S165)
Report Version: 4

Command: Oolite
Path:    /Applications/Games/Oolite/Oolite1.72.app/Contents/MacOS/Oolite
Parent:  WindowServer [64]

Version: Oolite version 1.72 (1.72)

PID:    675
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x30303030

Thread 0 Crashed:

Thread 1:
0   libSystem.B.dylib              	0x9002c3c8 semaphore_wait_signal_trap + 8
1   libSystem.B.dylib              	0x90030eac pthread_cond_wait + 480
2   com.apple.Foundation           	0x92bed22c -[NSConditionLock lockWhenCondition:] + 68
3   org.aegidian.oolite            	0x000d9c3c -[OOAsyncQueue dequeue] + 40 (crt.c:355)
4   org.aegidian.oolite            	0x001001b4 -[OOAsyncLogger loggerThread] + 308 (crt.c:355)
5   com.apple.Foundation           	0x92be60c0 forkThreadForFunction + 108
6   libSystem.B.dylib              	0x9002bd08 _pthread_body + 96

Thread 2:
0   libSystem.B.dylib              	0x9002c3c8 semaphore_wait_signal_trap + 8
1   libSystem.B.dylib              	0x90030eac pthread_cond_wait + 480
2   ...ple.CoreServices.CarbonCore 	0x90bc6984 MPWaitOnQueue + 224
3   ...thesis.MacinTalkSynthesizer 	0x0560f4bc MTBEWorker::WorkLoop(MTBEWorker*) + 168
4   ...thesis.MacinTalkSynthesizer 	0x0560e6f4 MTBEWorkerStartMPTask + 16
5   ...ple.CoreServices.CarbonCore 	0x90bc6794 PrivateMPEntryPoint + 76
6   libSystem.B.dylib              	0x9002bd08 _pthread_body + 96

--

Unrelated: I just witnessed a very strange docking at the grs station. I was testing the collision behaviour of a control ship that flew around the outside of the station from coordinate set 2 -> 3. It suddenly disappeared at a height between 400 and 800 meters above the station centre. Far away from the docking area. According to my JS log function it collided and immediately was docked.

Code: Select all

Control ship gets coordinate set nr. 2: (200, 600, 800)
Control ship gets coordinate set nr. 3: (400, 900, 400)
GRS Controller DG34 collided with GRS Buoy Factory
GRS Controller DG34 with role buoy_repair_control docked at the GRS station

[JensAyton]

Oh good, no backtrace, my favourite. I suppose you weren’t by any chance doing something specific each time it happened? :-/

[another_commander]

I have received a crash report with Commies.oxp, astromine entity. Spawning this causes white crash (program stops running, no backtrace or errors in Latest.log). I have confirmed it on my system as well. Maybe it is not an actual crash, rather like some eternal loop situation?

[Ark]

Maybe it is not an actual crash, rather like some eternal loop situation?

By removing the following lines from shipdata.plist in the entity of astromine the problem is solved

<key>ai_type</key>
<string>astromineAI.plist</string>

So whatever it is that causes oolite 1.72 to crash is in the astromineAI.plist

But since in matters of AI I am a complete idiot I can not help any further
I think there is a AI expert in the forums

(Help us Eric one canobi you are our only hope)

[Eric Walch]

Maybe it is not an actual crash, rather like some eternal loop situation?

By removing the following lines from shipdata.plist in the entity of astromine the problem is solved

<key>ai_type</key>
<string>astromineAI.plist</string>
(Help us Eric one canobi you are our only hope)

I currently don't have it installed. However I didn't remember when I first crashed but the tree times after that I was always near the grs station and had spawned a special ship.
I could look if they use some identical AI command.

EDIT:
I re-added commies to my oxp list. But no crashes by waiting near a astromine for some time. I restored the original AI file for this. I changed the ENTER message on my system from:

Code: Select all

ENTER = ("spawn: comminer 3", "spawn: comminer2 1", "setStateTo: IDLE");

to

Code: Select all

ENTER = ("launchShipWithRole: comminer", "launchShipWithRole: comminer", "launchShipWithRole: comminer", "launchShipWithRole: comminer2", "setStateTo: IDLE")

It look better in my view. Ships are not added at once but but launched with intervals this way. At this I noticed there were 8 ships spawn around the station, but the AI only spawned 4. It had executed the ENTER message twice. It's a known bug, introduced in version 1.71 It can be bypassed by re-alocating the whole ENTER content to the UPDATE.

With the grs station I made sure that the suspect ship was not added, but still a new crash after waiting a few minutes around the station.

[Ark]

I re-added commies to my oxp list. But no crashes by waiting near a astromine for some time.

An easy way to reproduce the crash is to wait in the demo screen untill the astromine entity is ready to be seen

[another_commander]

Removing the spawn: comminer or launchShipWithRole: comminer entries from the astromineAI.plist makes it work. Leaving any of those inside ENTER, being it inside the GLOBAL state or not, will cause a crash whenever an astromine is spawned.

All this is referring to the Windows version, by the way. Mac does not seem to crash on this part, judging from Eric's post, but it does crash at some point, so I guess we'll have some fixing to do.

Eric, can you try installing Commies.oxp only, then navigating to the Astromine on the demo screen? I have an idea that the thing might actually be trying to launch ships as per its AI during the demo screen. In-game I have it working.

[Eric Walch]

This astromine crash happens when the station is added to the system. With me it just happens after longer time. It could be two different things.

For my crash I narrowed it down to a special ship that only does something special when the player is close to the grs station. It calls a function over a script message. When I call that function by hand, Oolite also crashes.

The function is about spawning a new ship and switching two ships. I look into it this evening witch part of the function generates the bug (it are only 10 lines) and report back.

[Eric Walch]

I found the line that crashed Oolite to desktop with me. It was just an unimportant line to log some variables. When I comment it out, the crashes stop. What am I doing: My ship's Ai is sending a sript massage with:

Code: Select all

	"UNLOADING" = {
		ENTER = (performStop, "pauseAI: 30", switchLightsOff);
		"ROLL_1" = ("sendScriptMessage: leavingDock", "setStateTo: REVERSE", switchLightsOn); 
		UPDATE = ("pauseAI: 30", "rollD: 5");
		EXIT = ();
	}; 

Than I added a log line for testing and than the normal log line. The last thing in the log before the crash is: "Leaving Dock"

Code: Select all

this.leavingDock = function()
{
    log("BuoyRepair", "Leaving Dock")
    if(worldScripts.buoyRepair.logging) log("BuoyRepair", this.ship.displayName + " at clamp "+this.clamp+", docked succesful " + (++this.dockings) +" times. Distance: "+ this.ship.position.distanceTo(this.grsStation))
  // remainder deleted
}

The variables in the logging are just numbers and it worked well with 1.71. And it does work well with svengali under 1.72. I removed all other oxp's except buoyRepair and the console. It still crashed on that line.

[Eric Walch]

I found the real culprit at last. It is in the distanceTo function that I use with this.ship.position.distanceTo(this.grsStation)

I tried in the console:
player.ship.position.distanceTo(system.mainPlanet)
This line also crashed Oolite on my mac. It is just strange it happens only on the mac and not with Svengali.

[Svengali]

It is just strange it happens only on the mac and not with Svengali.

Yes, it is working on Win. It seems we now have a few platform-differences. So let's hunt them down before the patch comes :-)

[Eric Walch]

I not always crash. Looking in the code I see that the function:

Code: Select all

this.checkPlayerDistance = function()
{
    if(this.ship.position.distanceTo(player.ship) < 30E3)
        this.ship.reactToAIMessage("PLAYER_CLOSE");
    else 
    {
       this.ship.reactToAIMessage("PLAYER_FAR_AWAY"); 
    }
}

Never crashed the system. NPC ships do execute this function well. But when I put an entity in the variable this.ship with the console and type: this.ship.position.distanceTo(player.ship) I Oolite does Crash. Also with:

Code: Select all

system.sun.position.distanceTo([1,1,1])
system.sun.position.distanceTo(player.ship)
system.sun.position.distanceTo(player.ship.position)

It sometimes crashes to desktop and sometimes just hangs indefinitely so I have to quit. But after above tests I looked in the crashlog and it added logs to a nonexisting application "000000000000000000000000000". Looking in that log I noticed Oolite was the active application. And this time a raport that looks much more promising. When I am right was one of the new changes about number-string conversion.

Code: Select all

**********

Host Name:      Eric-Walchs-Computer
Date/Time:      2008-11-07 10:23:58.907 +0100
OS Version:     10.4.11 (Build 8S165)
Report Version: 4

Command: 0000000000000000000000000000000000000000000000000000000
Path:    0000000000000000000000000000000000000000000000000000000
Parent:  WindowServer [62]

Version: Oolite version 1.72 (1.72)

PID:    228
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0xc0000000

Thread 0 Crashed:
0   org.aegidian.oolite            	0x00130704 JS_dtostr + 4356 (crt.c:355)
1   org.aegidian.oolite            	0x001304fc JS_dtostr + 3836 (crt.c:355)
2   org.aegidian.oolite            	0x0015c208 js_NumberToString + 276 (crt.c:355)

Thread 1:
0   libSystem.B.dylib              	0x9002c3c8 semaphore_wait_signal_trap + 8
1   libSystem.B.dylib              	0x90030eac pthread_cond_wait + 480
2   com.apple.Foundation           	0x92bed22c -[NSConditionLock lockWhenCondition:] + 68
3   org.aegidian.oolite            	0x000d9c3c -[OOAsyncQueue dequeue] + 40 (crt.c:355)
4   org.aegidian.oolite            	0x001001b4 -[OOAsyncLogger loggerThread] + 308 (crt.c:355)
5   com.apple.Foundation           	0x92be60c0 forkThreadForFunction + 108
6   libSystem.B.dylib              	0x9002bd08 _pthread_body + 96

[bmaxa]

Hm, distanceTo uses JS_ValueToNumber and JS_NewDoubleValue,
which does not use js_NumberToString, but I have linux version.

Greets, Branimir.

[bmaxa]

Just one question.
As I see js_NumberToString is called in this case only when call is made
through debug console and your crash happened in java script
lib during JS_CallFunction (which is also in java script lib),
before even getting to oolite distance function,
from doEvent:withArguments oolite function.
Do you have this crash when not using debug console?
Can you make core dump out of this?
I cannot reproduce bug as this function works on linux
either through external debug console or through oxp.

Greets, Branimir.

[bmaxa]

Further investigating this (pretty difficult to follow through
java script lib code), js_NumberToString is called
after VectorDistanceTo, but I can;t see how crash is
related to oolite code in this function as context is not touched and
this lib function just passes buffer (from local stack)
which will be populated by either IntToString or JS_dtostr
depending on jsdouble value which is not pointer.
Either by this time stack is completely garbage or
there is jsdouble value that causes this functions
to crash. Difference on linux is that IntToString
is called internally rather then JS_dtostr
with system.sun.position.distanceTo(player.ship), depending on
JSDOUBLE_IS_INT(d, i) where d is passed jsdouble
and i is assigned from d.
I'll look no further

Greets, Branimir.