News:

SimuTranslator
Make Simutrans speak your language.

[r7352] Crash : crossing_t::crossing_t() requested ...

Started by gauthier, November 10, 2014, 01:33:55 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

gauthier

Happens with pak128 ~2.5.1 when I try to create a new map covered with snow. I checked on a working map that all types of crossings (road-rail-canal) were working.

Ters

Very misleading error, because it does not come from crossing_t::crossing_t(), but (most likely) from grund_t::neuen_weg_bauen().

The crossing in question seems to be road and water. Timeline and top speeds might be an obstacle to actually finding a crossing. That's all I can see for the moment.

gauthier

There's no intro/retire date defined for these crossings in pak128, and I don't understand how the speed can be a problem. I made a few attempts, as I said, this bug seems to be related with snow (it happens everytime I decrease winter snow level to sea level unless I create the map without towns => without roads).

Ters

I can't see snow being part of the logic at all. The error message can come from one of two places, one in neuen_weg_bauen (build new way) and the other in rdwr (saving and loading game). In both cases, it is crossing_logic_t::get_crossing that has failed to find any crossings. crossing_logic_t::get_crossing only takes five parameters: way type and maximum speed of both ways, and the current date (year and month). There is nothing else used, apart from the crossing description from the pak set.

Update
Quote from: gauthier on November 10, 2014, 09:00:51 PM
There's no intro/retire date defined for these crossings in pak128
Yes there are. All crossings are available from 1900 only. I haven't checked if this is the default that is used because nothing else is defined, but this introduction date should be what the game cares about in any case.

It doesn't appear that town halls like the artic, which might somehow cause unusual town placements that in trun cause the game to generate road-water crossings it otherwise wouldn't tend to do.

gauthier

QuoteI can't see snow being part of the logic at all.
Neither I can't, but that's what my tests say  :-X

QuoteYes there are. All crossings are available from 1900 only.
I meant that no date was defined in dat files (just checked twice). I thought that default intro date was 1800  ??? Anyway I tried making the map in 1930, moreover these crossings are built well over rivers without low winter snowline.

QuoteIt doesn't appear that town halls like the artic, which might somehow cause unusual town placements that in trun cause the game to generate road-water crossings it otherwise wouldn't tend to do.
I don't use artic climate, only winter snowline. It used to work well in older releases.

Ters

Quote from: gauthier on November 11, 2014, 11:33:42 AM
I don't use artic climate, only winter snowline. It used to work well in older releases.

I thought you meant that there was always snow all the way down to sea level.


DrSuperGood

Is a crash really necessary in this case? I would think logging the error and then going to some "safe" behaviour would be a better solution. If there is no such crossing then one of the two ways should be retained while the other is not built. In the case of roads crossing water this would mean the water should be retained and the road discarded. It might produce ugly results but in that situation another bug/error might be the cause to investigate. If it is a small visual anomaly then a few manual touch ups would be better than a crash.

Ters

Quote from: DrSuperGood on November 11, 2014, 06:22:00 PM
Is a crash really necessary in this case? I would think logging the error and then going to some "safe" behaviour would be a better solution.

One might argue that crashing is never really necessary. I think the problem here might be that it can be a long way out to some place where the situation can be handled. The code must also roll back some of the constructions that has taken place (the second way has already been placed on the tile at this point if I remember correctly), or be rewritten to perform such steps in an atomic transactional scope. This is easier said than done.

A piece of software I work on profesionally has serious problems with handling errors, and it's attempts to limp along usually failed. So I modified it to first try to drop out of it's current state, to a state somewhat comparable with the demo map and menu in Simutrans, unless it failed when already in that state, in which case the program terminates completely. It was an improvement in this case, because the users where no longer fooled into thinking they could continue, which they rarely could, since the internal data was no longer in a consistent or legal state. Making the application exception safe, so that errors left the data in the previous state, would have been better, but we don't have the resources. (In my defence, the error prone code was written before I was hired. I try to be more concious about this the new applications I write.)

prissi

First is a search whether there is a crossing avialable. However, it seems when building the possible existent crossing it cannot be built. That is a valid reason for a crash, i.e. an expected preconditions is not fulfilled. It should not have started building a crossing in the first place there.

EDIT: I got artic crossings without crash. Please provide a map number and other settings.

gauthier

You might have to try several times (crashed after the second try).

TurfIt

Lack of intro date for the road water crossing is the immediate problem. Roads are available from year 1, townhalls from 1720, but the crossing only from 1900. On new map creation, the cities grow slowly from the first possible date (earliest date with roads and townhalls), 1720 in this case. If the growth causes it to try crossing the river before 1900 - crash.

For some reason, the timeline is ignored when checking if a road crossing can be built, but is then enforced when it actually builds it.
Changing bauer\brueckenbauer.cc::196 from:

if(  (ribi_t::doppelt(ribi) ^ ribi_t::doppelt(check_ribi) ) == ribi_t::alle  &&  crossing_logic_t::get_crossing(wt, w->get_waytype(), 0, 0, 0)  ) {


to:

if(  (ribi_t::doppelt(ribi) ^ ribi_t::doppelt(check_ribi) ) == ribi_t::alle  &&  crossing_logic_t::get_crossing(wt, w->get_waytype(), 0, 0, sp->get_welt()->get_timeline_year_month())  ) {

seems to fix things, but I'm not sure of the implications....

prissi

I think that should be fixed. However it should not crash when it is available (as it is with the above settings. Moreover, I *got* a water crossing when generating such games. Without crashing.

TurfIt

Yes, water crossings do show up, except if they are requested before 1900 by city growth, which causes the above crash. It takes several map creations for the conditions to occur due to the randoms involved, try a much larger map - 2048 x 2048 or so, with a max number of rivers, and max river length, and 500 or so citys with a 10000 median size, the climate/snowline is irrelevant. Even then the crash only occurs once every ~10 creations...

Specifically the slow growth section in karte_t::distribute_groundobjs_cities():

/* grow gradually while aging
* the difference to the current end year will be halved,
* while the growth step is doubled
*/

results in attempts at crossings as early as 1720.

The code in my last post from brueckenbauer.cc  check_tile() ignores the timeline in its call to crossing_logic_t::get_crossing(), but grund_t::neuen_weg_bauen() enforces the timeline in its call and hence the fatal error.
I'm not sure of the implications of simply adding the timeline check into the check_tile() call on other routines that use this - I'm not terribly familiar with the whole bauer sections of code which get rather convoluted...




gauthier

Quote from: prissi on November 13, 2014, 04:08:15 PM
I think that should be fixed. However it should not crash when it is available (as it is with the above settings. Moreover, I *got* a water crossing when generating such games. Without crashing.
Nice ! I'm trying a nightly build in a couple of days.