Regular crashes are back with 1.73.4 :(

Screet · Post by **Screet** » Fri Oct 02, 2009 1:56 pm

Kaks wrote:
Why don't you try and PS.spawn() the pod that crashed your scoop (with js debug console, of course)? Once we know which one constantly reproduces this crash, we should be able to look at it & fix the Oolite code.

Looks like I really need to attach my stick to the development machine. Another crash, same situation, only that it was an escape pod that should have been scooped. Instead of the scooping sound the app simply closed itself.

Screet

JensAyton · Post by **JensAyton** » Fri Oct 02, 2009 11:50 pm

Kaks wrote:
The difference between XML and js is that extreme.

Not only that, but JS will become several times faster in future releases (up to 40 times faster on some types of code according to benchmarks, but not that good for most Oolite code). Legacy scripts should be faster in 1.73 than earlier versions, as a side effect of the security changes, but I haven’t measured it and there are no plans to work specifically on performance for legacy scripts.

Eric Walch wrote:
Kaks wrote:
About flagging up legacy scripts in the log, it's a really good idea, I don't yet know how easy it's going to be to implement, though! :)
Any script name in the list that is shown on startup that has no version number is likely a plist script. So you can easy recognise them already.
(It is possible to add versions to a script.plist but I never noticed that be used outside Oolite)

This is true. The mechanism for adding version numbers to legacy scripts wasn’t publicised, and it isn’t backwards-compatible (I believe 1.65 will actually crash). If you’re writing legacy scripts that aren’t intended to be 1.65-compatible, you’re doing it wrong, so there’s really no situation where it makes sense to use this.

Screet · Post by **Screet** » Sat Oct 03, 2009 12:29 am

Screet wrote:
Looks like I really need to attach my stick to the development machine. Another crash, same situation, only that it was an escape pod that should have been scooped. Instead of the scooping sound the app simply closed itself.

Hmmm. Could not sleep. One hour, four crashes. All from cargo containers just about to be scooped...and it's all different containers, even escape pods. Only once did I hear the beginning of the scoop sound.

The crashes seem to happen roughly every 30 scooped containers/pods.

However, there's something interesting...might be coincidence from combat, but several times the last log entry was

Code: Select all

[Fuel Collector]: distance below 301

I really need to test that tomorrow from gdb...I just write this in the hope someone already has an idea from these observations.

Screet

Screet · Post by **Screet** » Sat Oct 03, 2009 12:57 am

Got it!

Again there was this distance below entry...so I did look at the fuel collector script:

Code: Select all

                                                   log("Fuel Collector", "distance below 301")
                                                    log("this.DerelictCheckTimer is"+this.DerelictCheckTimer)

Since there should ALWAYS have been two log entries, it's now clear that the second call to log crashes oolite.

Screet

Cmd. Cheyd · Post by **Cmd. Cheyd** » Sat Oct 03, 2009 5:00 am

Screet - Try it as:

Code: Select all

log("Fuel Collector","distance below 301");
log("Fuel Collector","this.DerelictCheckTimer is " + this.DerelictCheckTimer);

Wiki pages · Post by **Thargoid** » Sat Oct 03, 2009 7:49 am

I get this error quite often when testing. It's due to trying to approach something with nullAI.plist. The fuel collector script seems to get a bit confused (as it thinks said entity is a derelict to nick fuel from) and tries to trigger itself improperly (without its associated timer running).

You can do it quite repeatably (spawn an NPC ship, target it, type player.ship.target.setAI("nullAI.plist"), player.ship.target.desiredSpeed = 0 (for convenience) and then fly towards it - you should get the error popping up in logs/js console).

I've told Frame about it in the past, including how to trigger it. Presumably a fix will be forthcoming at some point.

Screet · Post by **Screet** » Sat Oct 03, 2009 7:50 am

Cmd. Cheyd wrote:

Screet - Try it as:

Code: Select all

log("Fuel Collector","distance below 301");
log("Fuel Collector","this.DerelictCheckTimer is " + this.DerelictCheckTimer);

Crash on the first scooped container, at the exact same position of the script.

That's strange. There's no derelict at all! Why does this code activate anyway? Probably the scooping only seems to trigger the crash because the cargo is usually at the ships position, but could it be that the scoopable things somehow are considered to be derelicts and thus crash things?

Screet

Screet · Post by **Screet** » Sat Oct 03, 2009 8:01 am

Thargoid wrote:
You can do it quite repeatably (spawn an NPC ship, target it, type player.ship.target.setAI("nullAI.plist"), player.ship.target.desiredSpeed = 0 (for convenience) and then fly towards it - you should get the error popping up in logs/js console).

It's much worse! There's no error entry in the log, but Oolite simply closes itself!

Screet

Wiki pages · Post by **Thargoid** » Sat Oct 03, 2009 8:03 am

In that case try removing fuel collector OXP and repeating?

Post by **Kaks** » Sat Oct 03, 2009 10:17 am

Hmmm, there seems to be a lot of wrongness still connected to timers. Screet, thanks for your detective work there, much appreciated. I still need to look into it properly, but based on some strange problems I had with timers in the past, I think all it's needed to stop fuel collector crashing oolite is to comment out the second log line:

Code: Select all

//log("Fuel Collector","this.DerelictCheckTimer is " + this.DerelictCheckTimer);

I won't be able to do much about it until tomorrow afternoon, but in the meantime:

Any fuel collector owner is advised to make that change, then restart Oolite while pressing shift (to 'flush the cache' i.e. to make Oolite aware of the change just made).

This should avoid those mid-scoop horribleness. Unless I'm completely wrong.

Screet · Post by **Screet** » Sat Oct 03, 2009 11:41 am

Kaks wrote:
I think all it's needed to stop fuel collector crashing oolite is to comment out the second log line:
Code: Select all
//log("Fuel Collector","this.DerelictCheckTimer is " + this.DerelictCheckTimer); 

Shortly after that line there's an if that checks for the timer. I moved the log line into that if clause. It did not activate in there, but on the last flight (one jump only) there would have been SEVEN crashes without that modification, as there are seven of these 301 entries in my log.

Screet

Post by **Eric Walch** » Sat Oct 03, 2009 1:06 pm

Kaks wrote:
Hmmm, there seems to be a lot of wrongness still connected to timers. .... but in the meantime:

Any fuel collector owner is advised to make that change, then restart Oolite while pressing shift (to 'flush the cache' i.e. to make Oolite aware of the change just made).

This should avoid those mid-scoop horribleness. Unless I'm completely wrong.

It is not related to timers because it only tries to log a property. There are two possibilities here. The player has not yet targeted a real derelict. Then the result is:

Code: Select all

distance below 301
Warning (strict mode): reference to undefined property this.DerelictCheckTimer
    Active script: "Fuel Collector" 0.06
    frame_fuel_collector.js, line 764: log("this.DerelictCheckTimer is"+this.DerelictCheckTimer)
     this.DerelictCheckTimer isundefined

Once the player encounters a derelict, the timer is created and than we get in the log:

Code: Select all

distance below 301
this.DerelictCheckTimer is[Timer nextTime: 921.439, interval: 1, not running, function: anonymous]

I assume the crashes with screet happen while trying to log an undefined property. Moving that log within the loop that test for the property solved it. So it is more the logging of an undefined property that crashes things.

Screet · Post by **Screet** » Sat Oct 03, 2009 1:30 pm

Eric Walch wrote:
I assume the crashes with screet happen while trying to log an undefined property. Moving that log within the loop that test for the property solved it. So it is more the logging of an undefined property that crashes things.

Yes, it definitely looks that way. I did not have derelicts and instead of the error messages you and Thargoid mentioned, Oolite simply closed. Vista did not even detect that it crashed.

Moving that line saved me over 20 crashes within two hours now (have been busy in anarchies)...and except my instable machines bluescreens there has not been a single problem now! And that's with ALL oxp's I like enabled!

However, I yet have to encounter a derelict from which I could attempt to steal fuel just to see if it works. I usually don't like to do that because in that case the ships cargo hold seems to be mysteriously emptied and I prefer to take their cargo

Screet

Post by **Eric Walch** » Sat Oct 03, 2009 1:36 pm

Screet wrote:
However, I yet have to encounter a derelict from which I could attempt to steal fuel just to see if it works. I usually don't like to do that because in that case the ships cargo hold seems to be mysteriously emptied and I prefer to take their cargo

Screet

I didn't play fair. I just targeted a ship and typed :

Code: Select all

> player.ship.target.setAI("nullAI.plist")
> player.ship.target.primaryRole = "shuttle"

into the console. This is enough to make the fuel collector think it is a real derelict.

Post by **Kaks** » Sat Oct 03, 2009 3:02 pm

Eric, I think the problem is with the timer .toString property, hence

Code: Select all

 based on some strange problems I had with timers in the past