Oolite 1.73.3 and 1.73.4 reliably crash, bad commodity.plist

[pmw57]

Was in Oolite PC but now in Testing and Bug Reports.

Oolite 1.73.3 and 1.73.4 reliably crash at Taranis station

Preparation:

• Fresh install of 1.73.3 or 1.73.4
• Taranis OXP
• A new and clean savegame, modified (as below) to place you to the Taranis station

Steps to reproduce:

• Enter Taranis station with gold, platinum, and/or gem stones. Enough so that when added on to your current load, is greater than your ships capacity
• Buy some luxuries
• Exit Taranis station

Step by step walkthrough:

• Start a new game and save it
• Edit the save game to place you in Lerelace system

<key>current_system_name</key>
<string>Lerelace</string>

<key>galaxy_coordinates</key>
<string>69 72</string>

• Load the save game so that you are now in the Lerelace system
• Buy a cheaper ship, so that you have some credits - something like the Cobra Mk I
• Buy gold and platinum. Enough so that their numeric value is larger than the ships capacity value.
• Also to help, buy the advanced space compass, witchdrive fuel injectors, and a docking computer
• Exit the Lerelace station
• Taranis is T on the compass
• Once docked at Taranis, open the commodities market

You should now see that gold, platinum and gem stones are listed in tons, and affect the ships load. Because you entered with some of them, you will now have a larger amount of items than the ship can carry. For example, 16 of 10 t.

• Buy the luxuries

You should now have a negative amount of luxuries, enough for your load to be at full capacity.

• Exit station with a negative amount of luxuries
• And the game crashes

1.73.4 crash details

Log Name: Application
Source: Application Error
Date: 30/09/2009 10:01:36 p.m.
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Computer: Paul-PC
Description:
Faulting application oolite.exe, version 0.0.0.0, time stamp 0x4ab8fd7c, faulting module objc-1.dll, version 0.0.0.0, time stamp 0x490b5e03, exception code 0x40000015, fault offset 0x00007383, process id 0x940, application start time 0x01ca4195e748a230.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2009-09-30T09:01:36.000Z" />
<EventRecordID>10727</EventRecordID>
<Channel>Application</Channel>
<Computer>Paul-PC</Computer>
<Security />
</System>
<EventData>
<Data>oolite.exe</Data>
<Data>0.0.0.0</Data>
<Data>4ab8fd7c</Data>
<Data>objc-1.dll</Data>
<Data>0.0.0.0</Data>
<Data>490b5e03</Data>
<Data>40000015</Data>
<Data>00007383</Data>
<Data>940</Data>
<Data>01ca4195e748a230</Data>
</EventData>
</Event>

[Commander McLane]

Don't know why it causes a crash, but the problem is in Taranis.oxp, to be precise in its commodities.plist. Following the Wiki explanation you see that the unit of commodities (t, kg, or g) is coded in the commodities.plist. 0 = t, 1 = kg, 2 = g.

If you open the commodities.plist of Taranis.oxp, you see that its creator has set all values to 0, except for luxuries. Bad idea. The last (10th) value for Gold and Platinum must read 1, and for Gem Stones 2. Correct that and you'll be fine.

What is happening now is that as soon as you enter the Taranis station, your kilogrammes of Gold and Platinum and your grammes of Gem Stones turn into tonnes. And of course this will overload your ship immediatly. Therefore the whole ship is suddenly pumped up 1000-fold (or in case of grammes a million fold), and the station a splode.

Still it is not clear why this crashes Oolite. Perhaps the new overload-avoidance handling in the code, when you scoop, has something to do with it?

[Kaks]

Thanks for spotting both the bug, and the Taranis OXP itself.

There's a commander sightsee included with the oxp, so you don't need to modify a savegame to get to Lerelace...

I've never used this oxp before, it looks like I missed out on some good stuff!

'Course we'll have to bugfix both Oolite (so it doesn't crash) & Taranis (so it doesn't do magic tricks with the cargo).

We'll have a look at the Oolite bug & report back later on...

[another_commander]

Simply put, the code has not predicted that someone would go and change the units of Gemstones, Platinum and Gold from g/kg to t. From there on, it rollercoasters to crash fairly quickly as cargo arrays are overflowed, integers meant to be positive become negative etc etc.

BTW, I would like to remark here that pmw57's report is a bright example of how a bug report should be. I invite anyone submitting problem reports to have a good thorough look in this one, see what a REAL bug report looks like and compare it to the "Oolite crashed. What gives?" that we get from time to time.

[pmw57]

Simply put, the code has not predicted that someone would go and change the units of Gemstones, Platinum and Gold from g/kg to t. From there on, it rollercoasters to crash fairly quickly as cargo arrays are overflowed, integers meant to be positive become negative etc etc.

BTW, I would like to remark here that pmw57's report is a bright example of how a bug report should be. I invite anyone submitting problem reports to have a good thorough look in this one, see what a REAL bug report looks like and compare it to the "Oolite crashed. What gives?" that we get from time to time.

Thanks guys. I've made the correction locally, and look forward to updates propagating out.

[Eric Walch]

Thanks guys. I've made the correction locally, and look forward to updates propagating out.

As I uploaded the last 1.1 version, I'll upload a 1.2 version soon. I just changed this wrong definition in my Taranis.oxp copy.

[pmw57]

'Course we'll have to bugfix both Oolite (so it doesn't crash) & Taranis (so it doesn't do magic tricks with the cargo).

That will be a good idea, because I've had a look at other OXPs that I have downloaded within the past week to find the same problem in some of those as well.

These are the affected OXPs (and stations/ships) which have a unit of 0 for Gold, Platinum, and/or Gem Stones.

Taranis - Taranis Station
Planet Fall - Main Military Base, Sub Military Base, Moon Surface Prison
RandomHits - Griff Space Bar
Taxi Galactica - Taxi Station
Dredgers - Super Dredger
Thargoid Carrier - Behemoth

All of these OXPs need to be "fixed".

Edit: The appropriate OXP threads have been updated to help advise about these needed updates as well.

[Thargoid]

Can we be a little more specific about when this bug triggers? Is it buying or selling for example? And is it specific to one OS, and/or version of Oolite?

The Planetfall examples all have the commodities all set to zero, so you cannot buy any tons of the items, although you can of course sell them. Does that trigger the bug? I can't say I've ever seen it actually happen on my machine.

Also at a more fundamental level is there actually any need to have the units available for setting in commodities.plist rather than being done automagically by name?

[pmw57]

Can we be a little more specific about when this bug triggers? Is it buying or selling for example? And is it specific to one OS, and/or version of Oolite?

The Planetfall examples all have the commodities all set to zero, so you cannot buy any tons of the items, although you can of course sell them. Does that trigger the bug? I can't say I've ever seen it actually happen on my machine.

The negative value issue occurs when buying an item.

Even when the price is set at 0, you can sell your items which add on to the stations stock. Then you can buy it back, and get the negative value problem.

For example:

[*]Start with 7 Gold, 9 Platinum, and 7 Gem Stones. The ships hold normally is still 0 of 10 t.
[*]Go to one of these locations that has Gold and others listed by the ton. Your ship now lists a load of 23 of 10 t.
[*]Sell the gold, and your ship has 16 of 10 t, and the station has 7 gold.
[*]Buy the gold, and your ship has 10 of 10 t, and you now have -6 of gold. (-6 + 9 + 7 = 10)

Notice that the station doesn't need to have anything for sale, nor does it need to list any prices, for this crash-causing bug to occur.

Also at a more fundamental level is there actually any need to have the units available for setting in commodities.plist rather than being done automagically by name?/color]

My initial guess is that this allows someone to be able to change the game so that instead of fur, you can have custom items instead.

[Commander McLane]

The bug seems to be triggered by entering the F8-screen with more valuables in your safe than you have cargo-space. Probably you will also need to make a transaction (any transaction). After you have bought or sold anything (not necessary valuables), your current cargo in hold has to be recalculated. At this time the kg and g are counted as t, so at this point the ugly things a_c is describing happen, inevitably leading to a crash.

So you won't notice anything, as long as you only have a few or no valuables on board.

[pmw57]

The bug seems to be triggered by entering the F8-screen with more valuables in your safe than you have cargo-space. Probably you will also need to make a transaction (any transaction). After you have bought or sold anything (not necessary valuables), your current cargo in hold has to be recalculated. At this time the kg and g are counted as t, so at this point the ugly things a_c is describing happen, inevitably leading to a crash.

So you won't notice anything, as long as you only have a few or no valuables on board.

Curse me and my mollyhawking ways.

Yes, if you sell at 0.0 you can then trigger the problem by buying it back, to result in a negative value for that commodity on your ship. Leaving the station with the negative amount causes crashy-boom things to occur to the program.

[Thargoid]

Fairy snuff. PF v1.23 now uploaded with the fix, as detailed here along with a download link for just the new plist file as a patch.

[another_commander]

The crash itself has been fixed in the latest trunk. However, the problem of weird behaviour with OXPs modifying the units of commodities still exists. I think Thargoid makes a very good point about units being not settable but decided by the game based on name or any similar identifier property. This would avoid the units conversion mess that can result as we have it now. Imagine an OXP switching commodities units randomly (computers in kg, gold in tons, radioactives in grams and so on).

[Eric Walch]

These are the affected OXPs (and stations/ships) which have a unit of 0 for Gold, Platinum, and/or Gem Stones.

Thargoid Carrier - Behemoth

All of these OXPs need to be "fixed".

Thanks for figuring these oxp's out. The Thargoid Carrier is even nastier. It contains the commodities of a complete other ship and not its own. When installed it changes the values for a behemoth.

However, the problem of weird behaviour with OXPs modifying the units of commodities still exists. I think Thargoid makes a very good point about units being not settable but decided by the game based on name or any similar identifier property. This would avoid the units conversion mess that can result as we have it now. Imagine an OXP switching commodities units randomly (computers in kg, gold in tons, radioactives in grams and so on).

And what happens if someone leaves out a commodity definition in the list or adds one with unknown name?

[Kaks]

Yes, it does seem that in this case Oolite is letting the scripted market do a bit too much.
This particular issue is already known to affect quite a few oxps, and there might well be a few more affected oxps that we (I mean pmw57, really) haven't noticed yet.

Thinking about it, letting any script override a commodity unit of measure sounds very much like A Bad Idea, besides making the ooniverse that exta bit more inconsistent. Let's remove the unit override!

edit:

And what happens if someone leaves out a commodity definition in the list or adds one with unknown name?

very good questions: I'll be back to you with some proper answers anon!