Reproducible crash with trunk build 1.75.0 4071

[Screet]

Hi,

finally I've found what's causing my trunk build 1.75.0 4071 to crash upon launch: I still had Fuel Collector v.0.06 installed. Removing that oxp, the crash is gone.

Since there's not even a report in the logs as to what is causing the crashes, it might be a good idea if someone who's good at debugging could have a look at that.

Screet

[Screet]

First I thought that it might be another unchecked timer...but it turns out that this line is causing Oolite to crash without a report hinting at the cause:

let sun_distance = this.theplayer.position.distanceTo(system.sun)+system.sun.radius

When I change it to let sun_distance = 0 it's not crashing anymore. Further indication that this calculation is causing the problem: A log right after that calculation is not showing up in the log unless I change the line to the dummy version.

EDIT: since the script does take care of different oolite versions, this.theplayer expands to player.ship and I've also tried it with that one directly - it still crashes. It does even crash when I try to use the distance from the players ship towards the players ship instead of requesting distance to sun. I can even log this before:
[Fuel Collector]: this.theplayer: [PlayerShip "Caduceus Omega" position: (-48596.2, 59641.5, 428088) scanClass: CLASS_PLAYER status: STATUS_IN_FLIGHT]

However, any following distance calculation is causing Oolite to crash. If I disable only that line, I can fly around.

Screet

[JensAyton]

Does player.ship.position.distanceTo(system.sun)+system.sun.radius in the console crash?
What’s your oolite.jsVersion?

[Screet]

That'll take me a bit of time - I'll have to walk with my dog soon and it may be that I won't have time afterwards&tomorrow.

However, the interesting part is that the crash did not happen with this installer: OoliteInstall-1.75.0.3902.exe

Screet

[Screet]

Does player.ship.position.distanceTo(system.sun)+system.sun.radius in the console crash?
What’s your oolite.jsVersion?

OK, my dog was too afraid to go outside and I finally managed to download the debug console/oxp. Had to increase the version number from 1.74 to also allow 1.75 - I hope that's OK, I did not find a newer version.

Ran the command in the console - connection closed, Oolite gone, nothing in the logs.

oolite.jsVersion returns 185

Screet

[another_commander]

Are you using the trunk version of the Debug.oxp? An outdated version of this OXP could cause unpredictable issues with the new JS engine, as there have been many changes to that since 1.74.2. Also, if you install the JavaScript Interface Tests.oxp (residing in the tests folder of the trunk) and run from the console ooRunTests(), do the tests pass?

I installed the Fuel Collector OXP v0.06 and, apart from some editing in order to replace the obsolete in trunk hasEquipment("EQ_*") occurences with equipmentStatus("EQ_*)=="EQUIPMENT_OK", the OXP seems to run OK and I can see messages that the FC is operating and fuel is increasing while I am cruising in space.

Finally, on my system, executing the command from the console returns a value, as expected. Below is what I get if I execute it right after launching from Lave:

Code: Select all

> player.ship.position.distanceTo(system.sun)+system.sun.radius
982240.28125

[Screet]

Are you using the trunk version of the Debug.oxp? An outdated version of this OXP could cause unpredictable issues with the new JS engine, as there have been many changes to that since 1.74.2. Also, if you install the JavaScript Interface Tests.oxp (residing in the tests folder of the trunk) and run from the console ooRunTests(), do the tests pass?

I have the debug.oxp that I found linked, there were different versions for different oolite versions with 1.74.x being the newest and I had to manually edit the file to allow usage under 1.75

I had a look at the debugOXP in the trunk, but there were only sources and such, no oxp?

However, I just copied the JavaScript Interface Tests.oxp to my installation and ran the tests (with the presumably outdated debug.oxp). All 68 tests completed ok.

The problem, whereever it does come from, is new, as I wrote. The version I did build on december 23 did not have that problem, but OoliteInstall-1.75.0.4053.exe already had it.

Screet

[JensAyton]

I had a look at the debugOXP in the trunk, but there were only sources and such, no oxp?

Run “make” in the Debug OXP directory, and it will produce “Basic debug.oxp” which does everything Debug.oxp does except on Macs.

[Screet]

Ahhh, my panic-dog made me stay at home instead of joining the family trip - but that gave me time to think.

Oolite once had the problem that it required Data Execution Prevention (DEP) to be turned off, but that was fixed. However, between the versions I wrote, that did change. When I turn off DEP, the crash with Fuel Collector is gone.

Still I do believe that it shows some problem.

Screet

[JensAyton]

Hmm. I thought that was fixed with a GNUstep update a while ago.

[Screet]

Yes, it was fixed, for quite some time and even the version I did build on december 23rd was OK concerning that - but when I did build few days ago, the problem somehow was "reintroduced" to the game.

At least that's better than not having an idea of what's wrong at all.

Screet

[JensAyton]

Yes, it was fixed, for quite some time and even the version I did build on december 23rd was OK concerning that - but when I did build few days ago, the problem somehow was "reintroduced" to the game.

Wrong type of fixed.

The DEP issues – at least, the ones we’ve had in the past – were triggered by code in GNUstep. We’ve worked around that by avoiding the relevant code path (message forwarding). I was under the impression that this problem in GNUstep didn’t exist any longer, so we didn’t need to to work around it (by unwrapping weak references).

However, as far as I can see the only weakrefs involved in that expression (specifically, the this values in PlayerShipGetProperty() and SunGetProperty()) are unwrapped in OOJSObjectGetterImpl(). I’ve added an assertion in r4076 to rule these out, please test.

[Screet]

However, as far as I can see the only weakrefs involved in that expression (specifically, the this values in PlayerShipGetProperty() and SunGetProperty()) are unwrapped in OOJSObjectGetterImpl(). I’ve added an assertion in r4076 to rule these out, please test.

I've just built 4077 and installed it - the machine for building and playing are different ones. Should I try to set things up for testing on the building machine? I'm not sure if it will show the same problems as that one has XP 32 while I play under Vista 64. However, that XP machines graphic card is the main problem.

4077 does show the same crash with DEP on when FuelCollector tries to make that calculation. After turning DEP off it's working. Thus there's no visible change in behaviour.

Screet

[bovinespirit]

Just a quick note for anyone else who wants to use Fuel Collector with v1.75... I used the 'sed' command to replace all the instances of 'hasEquipment'. It's available on MacOs and Linux but probably not on Windows. If you go to the OXP/Scripts directory and run this command:

Code: Select all

sed 's/hasEquipment("EQ\_\([A-Z_]*\)")/equipmentStatus("EQ_\1")=="EQUIPMENT_OK"/g' < frame_fuel_collector.js > frame_fuel_collector_new.js

then a new file will be created with the commands substituted. The new script seems to work fine on both 1.75(trunk) and 1.74.2.

More on 'sed' here: http://www.grymoire.com/Unix/Sed.html

[Kaks]

Good news on the windows front regarding sed: there's a free version available on the interwebs, and notepad++ allows you to do sed like substitutions fairly easily.

Regarding DEP, I'm momentarily windowsless for dev purposes, but I'll see what I can do this weekend, if I get the time! (BloodyRL - patent pending in way too many places! )