News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Game crashes when deliver a specific good

Started by NNW, January 24, 2016, 11:41:33 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

NNW

I have a Problem.
We have a factory (pak128.german) that produces Sugar and get Sugarbeets as Input. This Factorys works so far (i have changed nothing in the DAT File!), but now it produces crashes, if the Sugarbeet Farm delivers to this factory and another line want to carry the sugar to the bakery. ATT the Truck arrives at the Factory=>Crash. Same if i place a scond Farm and the Convoy try to load the good from this....

So my question: Why ST crashes when i try to transport this 2 goods?

This are the content of our DAT Files:

The Sugar Factory:


Obj=factory
Name=NDT_alte_Zuckerfabrik
copyright=pumuckl999
pax_level=20
intro_year=1930
intro_month=1
location=City
DistributionWeight=50
Productivity=200
InputGood[0]=Zuckerrueben
InputCapacity[0]=300
InputSupplier[0]=3
InputFactor[0]=30
OutputGood[0]=Zucker
OutputCapacity[0]=300
OutputFactor[0]=100
electricity_amount=75
climates=mediterran, tropic, desert
expand_probability=5000
expand_minimum=30
expand_range=100
expand_times=2
electricity_boost=1000
MapColor=119
dims=1,2,4
BackImage[0][0][0][0][0][0]=NDT_alte_Zuckerfabrik.0.0
BackImage[0][0][0][1][0][0]=NDT_alte_Zuckerfabrik.0.1
BackImage[0][1][0][0][0][0]=NDT_alte_Zuckerfabrik.0.2
BackImage[0][1][0][1][0][0]=NDT_alte_Zuckerfabrik.0.3
BackImage[0][0][0][0][0][1]=NDT_alte_Zuckerfabrik.0.4
BackImage[0][0][0][1][0][1]=NDT_alte_Zuckerfabrik.0.5
BackImage[0][1][0][0][0][1]=NDT_alte_Zuckerfabrik.1.0
BackImage[0][1][0][1][0][1]=NDT_alte_Zuckerfabrik.1.1
BackImage[1][0][0][0][0][0]=NDT_alte_Zuckerfabrik.1.2
BackImage[1][0][0][1][0][0]=NDT_alte_Zuckerfabrik.1.3
BackImage[1][0][1][0][0][0]=NDT_alte_Zuckerfabrik.1.4
BackImage[1][0][1][1][0][0]=NDT_alte_Zuckerfabrik.1.5
BackImage[1][0][0][0][0][1]=NDT_alte_Zuckerfabrik.2.0
BackImage[1][0][0][1][0][1]=NDT_alte_Zuckerfabrik.2.1
BackImage[1][0][1][0][0][1]=NDT_alte_Zuckerfabrik.2.2
BackImage[1][0][1][1][0][1]=NDT_alte_Zuckerfabrik.2.3
BackImage[2][0][0][0][0][0]=NDT_alte_Zuckerfabrik.2.4
BackImage[2][0][0][1][0][0]=NDT_alte_Zuckerfabrik.2.5
BackImage[2][1][0][0][0][0]=NDT_alte_Zuckerfabrik.3.0
BackImage[2][1][0][1][0][0]=NDT_alte_Zuckerfabrik.3.1
BackImage[2][0][0][0][0][1]=NDT_alte_Zuckerfabrik.3.2
BackImage[2][0][0][1][0][1]=NDT_alte_Zuckerfabrik.3.3
BackImage[2][1][0][0][0][1]=NDT_alte_Zuckerfabrik.3.4
BackImage[2][1][0][1][0][1]=NDT_alte_Zuckerfabrik.3.5
BackImage[3][0][0][0][0][0]=NDT_alte_Zuckerfabrik.4.0
BackImage[3][0][0][1][0][0]=NDT_alte_Zuckerfabrik.4.1
BackImage[3][0][1][0][0][0]=NDT_alte_Zuckerfabrik.4.2
BackImage[3][0][1][1][0][0]=NDT_alte_Zuckerfabrik.4.3
BackImage[3][0][0][0][0][1]=NDT_alte_Zuckerfabrik.4.4
BackImage[3][0][0][1][0][1]=NDT_alte_Zuckerfabrik.4.5
BackImage[3][0][1][0][0][1]=NDT_alte_Zuckerfabrik.5.0
BackImage[3][0][1][1][0][1]=NDT_alte_Zuckerfabrik.5.1


the Sugarbeet Farm:


Obj=factory
Name=NDT_alter_Bauernhof
copyright=pumuckl999
pax_level=5
intro_year=1930
intro_month=1
location=land
DistributionWeight=50
Productivity=100
OutputGood[0]=Zuckerrueben
OutputCapacity[0]=100
OutputFactor[0]=100
electricity_amount=10
min_fields=2
max_fields=6
probability_to_spawn=5000
fields[0]=Zuckerrueben_Feld
production_per_field[0]=20
storage_capacity[0]=10
has_snow[0]=1
expand_probability=5000
expand_minimum=5
expand_range=25
expand_times=2
electricity_boost=1000
climates=tropic, desert
MapColor=40
dims=1,1,4
BackImage[0][0][0][0][0][0]=NDT_alter_Bauernhof.0.0
BackImage[1][0][0][0][0][0]=NDT_alter_Bauernhof.0.1
BackImage[2][0][0][0][0][0]=NDT_alter_Bauernhof.0.2
BackImage[3][0][0][0][0][0]=NDT_alter_Bauernhof.0.3
BackImage[0][0][0][0][0][1]=NDT_alter_Bauernhof.1.0
BackImage[1][0][0][0][0][1]=NDT_alter_Bauernhof.1.1
BackImage[2][0][0][0][0][1]=NDT_alter_Bauernhof.1.2
BackImage[3][0][0][0][0][1]=NDT_alter_Bauernhof.1.3

Dwachs

Could you try with the recent nightly build? There was a bug fixed which crashes in factory code.

Please upload a savegame if the crash also happens in the nightly builds.
Parsley, sage, rosemary, and maggikraut.

Frank

#2
sorry for german

(Don't be sorry, I fixed it to fit the rules - German is allowed, just a translation has to be posted in the board's language first :) —Isaac Eiland-Hall)

[EN] had it briefly recreated with 120.1.2 and pak128.german 0.8 - Win 7 64bit

The crash comes with me when the truck (which 9t for farm. Goods) arrives at the old farm (NDT_alter_Bauernhof).

looks like that is triggered by the crash invite into the vehicle

Goods are already at the station

[DE] habe es kurz nachgebaut mit 120.1.2 und pak128.german 0.8 - Win 7 64bit

Der Absturz kommt bei mir, wenn der LKW ( der 9t für landw. Güter ) beim alten Bauernhof ( NDT_alter_Bauernhof ) ankommt.

sieht so aus, das der Absturz vom einladen ins Fahrzeug ausgelöst wird

Waren sind schon an der Station

NNW

- I try it tomorrow.
- I cant give you a save, because it contains some new/altered factorys, with new object name.

@Frank: Its good that you had the same bug, so i know now sure its not my fail, by altering/reorder the params of our factory lines.

DrSuperGood

Do note that altering the pakset with existing saves can potentially lead to crashes as much of the loading depends on reading values from the pakset. If you want to heavily alter objects you should probably obsolete the existing ones and then add new, differently identified ones for future games.

Frank

Quote from: NNW on January 24, 2016, 07:02:30 PM
...
@Frank: Its good that you had the same bug, so i know now sure its not my fail, by altering/reorder the params of our factory lines.

I think bug in good-dat

NNW

I can transport it with trains and airplanes, but NOT with trucks ???

@DrSuperGood

All altered Factorys has new ObjectIDs and the old ones are deactivated with the Param DistributionWeight=0. This Works perfect with the Book, furniture, medicine and Steel Line.

The Sugarline works so far, but now not! I have nothing altered on this two factory's. From where also comes the crashes?

Dwachs

Could you please test with a recent nightly? If the crash happens there as well, then please upload a savegame together with the pakset directory. If you do not want to share it in public, you can send me a PM.
Parsley, sage, rosemary, and maggikraut.

NNW

I had tried it with the nightly=>Crash with Trucks :D

You can download the savegame from here: Savegame and the complete PAKSet Folder from here: Pakset

Dwachs

Could not reproduce it. The savegame also has no trucks transporting sugar or sugar beets.
Parsley, sage, rosemary, and maggikraut.

NNW

#10
[EN] go in the depot near the farm, choose a LKW for "Landw. Gueter" and the forelast route. Then let it transport the beets for a short while.....

[DE] Nimm einen LKW fuer landwirtschaftliche güter, und wähl die vorletze linie. Dann lass ihn die rueben zur fabrik transportieren. nach ~ 10 - 15 sekunden crasht das game sowohl mit der 120.1.2 wie auch dem nightly

Dwachs

build MAN trucks (16t capacity) no luck / no crashes (with r7744)
Parsley, sage, rosemary, and maggikraut.

TurfIt

Crashes repeatably when a  MAN_19230_DF_Landwirtschaft  assigned to (158) line arrives to load for the 4th time.
Program received signal SIGSEGV, Segmentation fault.
0x0075acd4 in quickstone_tpl<convoi_t>::operator!= (this=0x8, other=...)
    at dataobj/../tpl/quickstone_tpl.h:258
258             bool operator!= (const quickstone_tpl<T> &other) const { return entry != other.entry; }
(gdb) bt
#0  0x0075acd4 in quickstone_tpl<convoi_t>::operator!= (this=0x8, other=...)
    at dataobj/../tpl/quickstone_tpl.h:258
#1  0x0076580a in slist_tpl<quickstone_tpl<convoi_t> >::is_contained (
    this=0x1b8b8f84, data=...) at vehicle/../tpl/slist_tpl.h:276
#2  0x005baffe in haltestelle_t::request_loading (this=0x1b8b8c60, cnv=...)
    at simhalt.cc:854
#3  0x005a345d in convoi_t::laden (this=0x1b971fc0) at simconvoi.cc:2759
#4  0x0059d346 in convoi_t::step (this=0x1b971fc0) at simconvoi.cc:1162
#5  0x00607f4e in karte_t::step (this=0x46ca1c8) at simworld.cc:4507
#6  0x00612eee in karte_t::interactive (this=0x46ca1c8, quit_month=2147483647)
    at simworld.cc:7067
#7  0x005ce4c1 in simu_main (argc=1, argv=0x3c2fc0) at simmain.cc:1311
#8  0x005d7563 in sysmain (argc=1, argv=0x3c2fc0) at simsys.cc:804
#9  0x0062f270 in WinMain@16 () at simsys_s.cc:714
#10 0x007debed in main (flags=1, cmdline=0x3c2fa0, inst=0x3c1f68)
    at C:/repo/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crt0_c.c:18

The loading_here slist head is corrupt after the 3rd departure erase()...

NNW

Strange is: I can transport the good with trains but not with trucks. So whats wrong with the trucks?

Ters

Quote from: TurfIt on January 26, 2016, 01:14:23 AM
Crashes repeatably when a  MAN_19230_DF_Landwirtschaft  assigned to (158) line arrives to load for the 4th time.
[...]
The loading_here slist head is corrupt after the 3rd departure erase()...

Hmm... there are two ways I can see that happening. One is a random rogue pointer. The other is sort of the opposite, yet the same, something like:


slist_tpl::iterator i1 = slist.begin();
slist_tpl::iterator i2 = slist.begin();
slist.erase(i1);
// Code unrelated to slist, but which allocates and uses memory. The memory that contained the node_t just erased.
slist.erase(i2);

Dwachs

Quote from: TurfIt on January 26, 2016, 01:14:23 AM
Crashes repeatably when a  MAN_19230_DF_Landwirtschaft  assigned to (158) line arrives to load for the 4th time.
...
The loading_here slist head is corrupt after the 3rd departure erase()...
The stop at the farm consists of a single tile. So the loading_here list should at most contain one convoi.

I could not get this to crash. You assigned only one convoi to this line? Do you happen to have the halt info window open?

Is there any method in the code that calls haltestelle_t::finish_loading?
Parsley, sage, rosemary, and maggikraut.

TurfIt

Single convoi only. Crashes 100% repeatably on the 4th visit to load. Dialogs open or closed doesn't matter. Debug and optimized builds crash. Didn't try gcc4.6 that wasn't desyncing for you with my save...

I also created a new save from right before it enters for the 4th time and the crash persists though loading such that it crashes upon the first visit. I'll look some more tonight.

I can't find anything that calls finish_loading.

Ters

#17
For me, it seems to crash the first time it loads after the stop is full.

Update:
Array index out of bounds at simhalt.cc line 2849.

Dwachs

This makes sense to crash: pak128.german has more than 64 goods, good type >64 is overflowing. The access at line 2849 writes out of bounds, and apparently into loading_here.

Curios enough, I still cannot reproduce this: for my gcc build, loading_here does not get corrupted, also the gcc4.9 build with address sanitizer does not complain.
Parsley, sage, rosemary, and maggikraut.

Ters

I used GCC 4.8.1 when building the executable I reproduced this with. sizeof(haltestelle_t) = 896

NNW

#20
I have reduced the number of goods to 64 and pushed out the factorys for this "superfluous" goods and that fix it! But why this crash only with trucks and not with trains?

TurfIt

Pure luck, or the train is hauling enough the stop never overcrowds.

Gotta love undocumented 'hidden' limits. Everywhere else 255 is the goods count limit. It's simple enough to expand the overcrowded array to handle the full 256, I don't see any other obvious places where >64 will cause issues... But >64 is a lot of goods!


Ters

Quote from: TurfIt on January 26, 2016, 06:22:33 PM
Gotta love undocumented 'hidden' limits. Everywhere else 255 is the goods count limit. It's simple enough to expand the overcrowded array to handle the full 256, I don't see any other obvious places where >64 will cause issues... But >64 is a lot of goods!

Well, the problem here, in case you haven't realized, is that the limit on this array is the goods category limit. You failed to enlarge the array when you changed overcrowding to track individual goods, rather than categories, back in October. So the bug isn't particularly old. If some centrally defined constants had been used in the first place, that wouldn't have been a problem.

TurfIt

Where is the goods category limit different than the goods limit?
Of course changing overcrowding to per good rather than per category makes it more likely to hit this 64 limit, and that was missed entirely that it was different from the 256 limit. But should a pak have >64 categories, same problem. Maybe Pak128.german will try for that next. :)

NNW

QuoteBut >64 is a lot of goods!

Yes. 64 is a lot but we have 68  :D
It seems our Pakset have a lot more (complex) factory lines than the other and most of the factorys need more than 1 input good for the (end) product.... and thats why....

Our Lines:

Furniture
Book
Medical
Waste
Machine
Computers
Cars
Bakery
Beverages
Convenience foods
Concrete and Cement
Ships

QuoteMaybe Pak128.german will try for that next.

No no no, 9 categories are enough for us :)

Dwachs

#25
Comitted a fix with r 7752. Thanks Ters for the help.

Edit: corrected revision number
Parsley, sage, rosemary, and maggikraut.

Ters

Quote from: TurfIt on January 26, 2016, 07:04:16 PM
Where is the goods category limit different than the goods limit?

simhalt.cc (before October), apparently. I don't know if there is a goods category limit anywhere else, beyond what the data type imposes, but the data type cannot impose any lower limit than 255.

DrSuperGood

Maybe in the long term some sort of dynamic flag type would be better? This change increased the array size from 8 to 64 bytes per stop always, a non-trivial increase for something that is seldom used (most paksets worked with the old limit of 64). Instead the number of bytes allocated could depend on pakset, with paksets that use more good types producing larger bitfields. Not only would this potentially have a much larger limit, but also for paksets which do not use a lot goods it could save on space. This would come at the cost of a pointer dereference since the array storage could no longer be part of the class.

NNW

If this make problems or goes to expense of the performance, then we should better reduce our goods list.

Dwachs

@DrSuperGood: That's true. It was however the easiest fix available. The increased memory footprint of these objects should have negligible impacts, there won't be millions of stops on a map. The data structure of the class is already quite a mess.
Parsley, sage, rosemary, and maggikraut.

michelstadt

#30
So does that mean that "changing overcrowding to per good rather than per category" introduced last october could be reversed?

EDIT: Has been fixed, thanks!

DrSuperGood

Worth noting that the new limit is now 256 goods. Might be a good idea to enforce the limit in the pakset loader so that it gracefully terminates simutrans if the limit is exceeded ("Cannot load pakset, more than 256 goods declared").

TurfIt


Ters

Yes, this had nothing do to with new limits or pak sets exceeding any existing limits. It was simply an array that slightly changed meaning, but wasn't big enough for the new job.

On the other hand, the limit on number of goods categories seems to be 32, according to ware_besch.cc. I'm not sure that is enforced anywhere. (This means that the overflow array was twice as big as it needed to, and that the actual limits in the game are not well known/defined.)

NNW

Quoteo that it gracefully terminates simutrans if the limit is exceeded ("Cannot load pakset, more than 256 goods declared").

Such Warning Messages are a very very good idea!
If ST Warns me as developer that that i have used a wrong paramter/value, than i can change it immediately....
Normally i run ST in Debug Mode when i work on our Pakset. The Warnings in the simu.log are in my opinion very helpfull, so such Warnings at program start would be helpful to.

DrSuperGood

If you run into limits you should still consider posting about it to the developers. It is entirely possible, like in this case, that the limits are smaller than intended or easily enlarged.