News:

SimuTranslator
Make Simutrans speak your language.

Query about quickstone error

Started by jamespetts, January 26, 2012, 08:53:40 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

In debugging an error, the origin of which I have not been able to trace, in Simutrans-Experimental's recent server game, I found that the program would crash in the following lines in quickstone_tpl.h:


if(  data[id]!=NULL  &&  data[id]!=p  ) {
                dbg->fatal("quickstone<T>::quickstone_tpl(T*,uint16)","slot (%d) already taken", id);
            }


It appeared to come from the code for loading stops, and when I manually moved the line of code execution past the error in a debugger, it would simply return to the breakpoint that I had set there many times over, indicating that, for a particular saved game, the error recurred many times. This was consistent on loading one particular saved game. I commented out the dbg->fatal line, expecting the game either to crash with some access violation when loading or the actual map to be corrupted or missing lots of data (I was hoping that it would help in diagnosing where the problem occurred), but, curiously, when loading the game with that line commented out, it seemed to work fine. More curiously, when then re-saving the game and opening in the released version without that line commented out, that new save also worked without difficulty, with the error not recurring.

Do any of the developers who have more understanding of how the quickstones work than I have any idea what might be going on here? I must admit to being quite mystified.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

If this is tandrad, most likely it could come from simware.cc on loading time. Aparently the halt id are scramble. As a result, those goods will go to other than their intended locations. It might or might not be fixed by a rerouting then.

However, I have never ever seen this in standard if the game was not completely broken, i.e. everything was a mess, not only this. Thus if experimental produced such a game again, then this hints at a worse error deeper.

As you have the savegame, you could easily look at the callback history in the debugger for which quckstone assignment failed.

jamespetts

Prissi,

thank you very much for taking the time to reply - that is most helpful. May I ask what you mean by "tandrad"? I am not familiar with the word, and cannot find it in the dictionary or a German to English translator (although, apparently it means "row of teeth" in Swedish).

The debugger call stack shows the error being triggered from the halt loading/saving routine when the game is reloaded. (It just recurred again on the server). It actually occurs for only four halts, with IDs of 970, 974, 975, and 981, all of which are consecutive and are the last four halts loaded. Using the breakpoint set on the line which always calls the method in which the error is produced, being:


self = halthandle_t(this, halt_id);


in the rdwr method of simhalt.cc, 970 only actually appears once as a "halt_id", which is the time that it produces the error.

Creating test objects of the type haltestelle_t* in quickstone_tpl.h using the code:


const haltestelle_t* TEST_1 = (haltestelle_t*)data[id];
const haltestelle_t* TEST_2 = (haltestelle_t*)p;


shows that the first object (that is, TEST_1; the object that has already been loaded) has a "self" with an id of 1017, whereas the new object has the "self" object with the correct id of 970. When I try to fetch their names using the code:


const haltestelle_t* TEST_1 = (haltestelle_t*)data[id];
const char* TEST_name_1 = TEST_1->get_name();
const haltestelle_t* TEST_2 = (haltestelle_t*)p;
const char* TEST_name_2 = TEST_2->get_name();


both TEST_name_1 and TEST_name_2 are "Unnnamed".

Checking for hitting the line:


self = halthandle_t(this, halt_id);


when halt_id == 1017, I indeed get a hit before the program loads 970. When it gets to that line with halt_id == 970, TEST_1 has the same address in memory as the halt that the id of 1017. Checking with:


const haltestelle_t* TEST_1 = (haltestelle_t*)data[id];
const char* TEST_name_1 = TEST_1->get_name();
const haltestelle_t* TEST_2 = (haltestelle_t*)p;
const char* TEST_name_2 = TEST_2->get_name();
const haltestelle_t* TEST_3 = (haltestelle_t*)data[1017];
const char* TEST_name_3 = TEST_3->get_name();


I find that TEST_3 == TEST_1 when id == 970. In other words, it seems to have copied the pointer that is supposed to be stored at data[1017] to data[970], whilst keeping the correct pointer at 1017. So, when I ignore the error by commenting out the fatal line (or changing it to a non-fatal error), the game loads as normal and no data are lost.

I wondered whether some corruption is caused on enlarging, but the enlarge() function is not called, so it cannot be that. Do you have any clues as to what might be going on here? Any thoughts would be appreciated! Thank you.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Spike


Dwachs

The problematic line is this

haltestelle_t::haltestelle_t(karte_t* wl, loadsave_t* file)
{
self = halthandle_t(this); /// remove this!!! self will be initialized in rdwr

Halts save their id number (ie the index in the quickstone), the self-handle will be restored during loading. This was changed some time ago to prevent problems with changed ids in network games, which messed up schedules etc.
Parsley, sage, rosemary, and maggikraut.

prissi


jamespetts

Thank you very much, Dwachs - that solved it! Very helpful. Does the same also apply to convoys and lines?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Dwachs

Parsley, sage, rosemary, and maggikraut.

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.