Trunk...a new crash when scooping splinters

Screet · Post by **Screet** » Sat Oct 10, 2009 3:49 am

Hi,

I updated to 2659 today...and since then I'm experiencing crashes once I try to scoop a splinter! That did work before (although that was with my old Mobo/CPU).

The log always reads:

Code: Select all

[script.javaScript.warning.ooliteDefinedError]: ----- JavaScript warning ("oreProcessorSplinter" 1.0): PlayerShip.canAwardCargo() is deprecated and will be removed in a future version of Oolite.
[script.javaScript.warning.ooliteDefinedError]:       ../AddOns/A - Oolite Shipyards Extension WiP V0.69.oxp/Scripts/op_splinter.js, line 43.

Screet

Post by **Kaks** » Sat Oct 10, 2009 8:58 am

Apart from telling you that canAwardCargo is going to be obsolete, there's nothing there to suggest the reason for the crash.

As a matter of not-so-idle curiosity, what is inside op_splinter.js ? That might actually show the code after canAwardCargo, and give us some actual pointers to where the problem is.

By the way the underlying changes & deprecation for canAwardCargo have been there since rev.2638. The only change made in 2659 was adding a new js function to trunk. Did that OSE script work ok in 2658?

Screet · Post by **Screet** » Sat Oct 10, 2009 9:22 am

Kaks wrote:
Apart from telling you that canAwardCargo is going to be obsolete, there's nothing there to suggest the reason for the crash.

As a matter of not-so-idle curiosity, what is inside op_splinter.js ? That might actually show the code after canAwardCargo, and give us some actual pointers to where the problem is.

It's the ore processor from eric and I believe that L did not modify it.

I did change the code into asking wether the used cargo is less than the max cargo, as that would not give warnings and even gold or gems do produce one ton cargo usage when gained this way.

Sadly, it did still crash, but without those warnings.

Interesting is that the script seems to call the ore processor script and that one does use a timer...and the scooping does not crash instantly but after a little while (probably the time when the scooping/processing should be done).

I tried to reproduce this on XP32 with a debug build in gdb - but I was not able to reproduce the crash there

Were it c++ I would search for an assert that contains code, but this is surely different here.

Since I used a newer installer after replacing the OS, I do not know wether it would have crashed on the old installation. With the previous version I was able to scoop splinters (although they were not always brought on board but the scoop did try endlessly until I would abort).

Screet

Post by **Kaks** » Sat Oct 10, 2009 9:33 am

It does start to sound as if this problem is timers related too. I'll fire up my buggy XP installation later on, and will try out the latest ore processor oxp, to see if it causes the same problems there...

Post by **Eric Walch** » Sat Oct 10, 2009 12:41 pm

Screet wrote:
I did change the code into asking wether the used cargo is less than the max cargo, as that would not give warnings and even gold or gems do produce one ton cargo usage when gained this way.

Sadly, it did still crash, but without those warnings.

Version 1.53 had a flaw that I checked canAwardCargo on scooping the splinter. That was probably an useless check at that place as only the fact that the splinter was scooped tells there was 1 ton room. In older oolite versions the scooping of a scripted barrel added 1 ton of cargo (than was not accounted for on the manifest page) and awarding the cargo added another. But i think this bug was already fixed with 1.72

The main check should have been within the worldscript. Now it can happen that I try to award 1 ton of ore while the hold is full. In the past this was no problem. Just nothing was added and it was mainly as cosmetic bug that you got a message of awarded cargo while there was nothing.
Current version 1.54 does this now correct. (But with deprecation warnings in the trunk log)

EDIT: I changed my code now so it also works with the new cargo handling. Will test it a bit further before uploading.

Screet · Post by **Screet** » Sat Oct 10, 2009 4:11 pm

Eric Walch wrote:
Current version 1.54 does this now correct. (But with deprecation warnings in the trunk log)

EDIT: I changed my code now so it also works with the new cargo handling. Will test it a bit further before uploading.

Please let me also test, as I've just downloaded 1.54 and used those files to replace mine (although I did not check wether OSE had 1.53 or 1.54 in). I still get the same reproducible crash

Any ideas?

Screet

Screet · Post by **Screet** » Sat Oct 10, 2009 5:35 pm

Hmmm. I /do/ have an idea now:

Minerals can be scooped, but I've not seen anything else on vista where it crashes.

With my development machine, I've only seen minerals and alloys somehow, but did not experience a crash.

Could it be that the type of cargo being extraced does cause a crash now? IIRC there recently was a bug in oolite introduced which caused it to crash with oxps that did give the wrong unit type for gold, gems and platinum...

Screet

Screet · Post by **Screet** » Sat Oct 10, 2009 5:52 pm

OK, further results:

XP 32: no problem (even with platinum)
XP 64: only minerals/alloys seem safe, otherwise kaboom...(also crashes with timer crash test)
Vista64: same as XP64

I fail to understand it. At first I was hoping it's related to the crashy timer thing, but it appears to be an additional 32/64bit issue?!?

Screet

Post by **Eric Walch** » Sun Oct 11, 2009 11:21 am

Screet wrote:
Eric Walch wrote:
Current version 1.54 does this now correct. (But with deprecation warnings in the trunk log)

EDIT: I changed my code now so it also works with the new cargo handling. Will test it a bit further before uploading.
Please let me also test, as I've just downloaded 1.54 and used those files to replace mine (although I did not check wether OSE had 1.53 or 1.54 in).

I uploaded it as version 1.55test. I haven't seen any issues with my computer. It now uses the new cargo handling planned for 1.74 and does not give deprecation warnings in the log. When I don't find any issues with it, it will become the 1.55 version.

Most timer issues were with timers in ship scripts because the script that contained the timer disappeared when the ship was removed. With this ore processor I made sure the timer was created in the worldscript itself. The splinters only call a worldscript function that start the timer within the worldscript. Or even better. The timer is only created on startup. After that I use only the start/stop option for that timer.

Screet · Post by **Screet** » Sun Oct 11, 2009 12:49 pm

Eric Walch wrote:
I uploaded it as version 1.55test. I haven't seen any issues with my computer.

Did scoop a splinter and had my cargo hold filled with 50 tons of radioactives

Screet

Screet · Post by **Screet** » Sun Oct 11, 2009 1:15 pm

That's really strange. I did add log messages to awardcargo in the script. Result:

[OreProcessor: awardCargo]: Gem-Stones:8
[OreProcessor: awardCargo]: Alloys:1
[OreProcessor: awardCargo]: Alloys:1
[OreProcessor: awardCargo]: Gold:6
[OreProcessor: awardCargo]: Alloys:1
[OreProcessor: awardCargo]: Alloys:1
[OreProcessor: awardCargo]: Gem-Stones:14
[OreProcessor: awardCargo]: Minerals:1
[OreProcessor: awardCargo]: Minerals:1
[OreProcessor: awardCargo]: Minerals:1

However, my cargo hold was filled with alloys this time. Looks like there's still something wrong - could that be oolite-internal?

As you can see, I did also scoop gold and gems without a crash. Whatever you did change, it solved the crash problem, but somehow does give too much cargo now.

I'd really like to know what crashed Oolite so that the bug could be fixed...

Screet

Post by **Eric Walch** » Sun Oct 11, 2009 1:32 pm

Screet wrote:
Eric Walch wrote:
I uploaded it as version 1.55test. I haven't seen any issues with my computer.
Did scoop a splinter and had my cargo hold filled with 50 tons of radioactives

Screet

Sounds familiar. I also scooped up things and suddenly my scoop icon became red because of a full hold. It contained 160 ton of food!
That was not from this oxp but from my cargo Wreck modification. Or my translation into the new method has a bug or there is a bug lurking in oolite.

The only thing I changed was the line that checks for Oolite versions. In the old way I never had an amount error and quantity is 1 for food.

Code: Select all

this.shipWasScooped = function (scooper)
{
    var message = this.ship.scriptInfo.message
    var cargotype = this.ship.scriptInfo.cargotype
    var quantity = this.ship.scriptInfo.quantity
	if (scooper.isPlayer)
	{
		if(quantity && quantity < 0) quantity= Math.ceil(Math.random()*(-quantity))
		if(quantity > 1) message = message.replace("gram ", "grams ");
		if(message) player.consoleMessage(quantity +" "+expandDescription(message));
		if(cargotype)
            if (0 < oolite.compareVersion("1.74")) scooper.awardCargo(cargotype, quantity)
            else scooper.manifest[cargotype.toLowerCase()] += quantity;
	}
	// do something with NPC once possible
}

Post by **Eric Walch** » Sun Oct 11, 2009 2:09 pm

I figured out what went wrong. The quantity was defined as string in script_info. When I change it to number, quantities are awarded correctly. Tthat means I can not use a open step shipdata.plist (only string) but must use a XML.plist to be able to define this script_info entry as number. (Or explicit convert it to number in the JS script. )

EDIT: I now updated the above test ore processor link. And on the wiki there is now a cargoWreck 1.5.1 that also should work correct on current trunk.

Screet · Post by **Screet** » Sun Oct 11, 2009 5:11 pm

Eric Walch wrote:
I figured out what went wrong. The quantity was defined as string in script_info. When I change it to number, quantities are awarded correctly. Tthat means I can not use a open step shipdata.plist (only string) but must use a XML.plist to be able to define this script_info entry as number. (Or explicit convert it to number in the JS script. )

EDIT: I now updated the above test ore processor link. And on the wiki there is now a cargoWreck 1.5.1 that also should work correct on current trunk.

I replaced them both...and guess what? I had it happen again. Very nice is, that the OP continues to extract gold and platinum to my safe while the cargo hold is full

Next attempt will be without CW. I was just too busy to test it all as I was running a debug-test on the other machine to track down the crash I get from OSE hardpirates. Turns out only to happen on 64bit

But finally I got a log report about which shaders are broken, someone must have added log functionality to that recently

Screet

Lestradae · Post by **Lestradae** » Sun Oct 11, 2009 5:30 pm

Screet wrote:
the crash I get from OSE hardpirates. Turns out only to happen on 64bit

The OSE hardpirates crash only happens on 64bit systems?

That's bad then, I can't hope to find the problem then. Not havin' a 64bit OS an' all