[Bug 3.11] Seemingly random crashes

[dantedarkstar]

I have experienced an extremely annoying bug, that's probably very hard to catch (assuming it's not something specific to my computer).

The game seems to crash SOMETIMES. If I recall correctly, it is almost always when I try to open the depot window. For example I had this tram depot that when I tried to open it after doing something, it would crash the game, but when I loaded savegame and directly went to the depot it didn't. Usually, it seems to crash everytime I haven't saved recently  :-\ (that's why it's so annoying)

Unfortunately, except for the windows error that says it tried to access the memory that cannot be "read", there is nothing. One thing that I CAN say, I NEVER encoutered this kind of crash pre 3.9 I think. I don't recall if it was happening in 3.9 (I didn't play with that one long), but certainly it did already in 3.10.

I will try one experiment - use GDI version of 3.11 for a while and see if the crashes persist (before 3.10 I obviously used GDI, but now use SDL). Note - the crashes like that never happened in standard simutrans 102.0 SDL, so it's not like SDL itself is buggy (I think), but on the other hand it may be something in late standard nightlies. Since I started experimental I don't play standard so it's hard to tell.

If I get any more info on this elusive bugger I'll post it.

[jamespetts]

Dante,

thank you very much for the report - most helpful. It is indeed annoying that it seems so random. If I can catch it in a debugger, I might be able to track it down. Can you post a saved game in which you are having trouble? Then I can run it for a while without saving it, and try opening the depot window. Thank you.

[tick tock]

I've experienced this one as well, but since it seems to happen so randomly there's not much useful information to offer.  As Dante mentioned, it can't be reproduced consistently and it doesn't seem to have any particular reason for occurring.  However, if I remember correctly, I've only had crashes with tram depots, I don't think there have been any other depots involved, although I'm not 100% certain of that.  And, for me, it's been when closing the depot window rather than opening.  That's all the information I can provide.  I don't know how useful savegames will be because it doesn't seem to be an error that can be reproduced on demand.

[jamespetts]

Tick Tock,

is it, by any chance, confined to electrified depots?

[dantedarkstar]

I just got this crash when opening AIR depot, and I sort of didn't electrify it. So it's not about electrification. Also, I was using GDI at that moment (for purpose of this test) so it's not related to SLD/GDI thing.

But I get the impression that is usually crashes when there's message that a new vehicle type appeared, then I "rush" to the depot to see the new goodies and BOOM ! I seem to remember this was quite often the case, but can't tell if it's a rule - but still this might help to reproduce the crash.

Anyway, this is the savegame that recently crashed when Concorde just became available and I went to depot to investigate. I was switched to different player when the message appeared, then I quickly switched to "human" and went to depot. The message about new airplane was still on the bar.
http://simutrans-germany.com/files/upload/Q4_xtmp.sve

[jamespetts]

Dante,

Thank you for that information. However, I am afraid that I am unable to load your saved game, using the latest nightly build of Pak64. May I ask - did you use any addons? An industry called "TANKE" says that it cannot find its "besch" (base type).

Edit: Oops - realised that this was actually Pak128! Will try again...

Edit 2: Can't reproduce the crashes, I'm afraid. However, I notice that you have put in enormous traffic spirals of no return in all of your cities - are you finding the traffic level excessive? Did you know that you can reduce the number of city cars by changing the "traffic density" setting in the "display" menu?

[tick tock]

Tick Tock,

is it, by any chance, confined to electrified depots?

I see that dante has already posted that he has had problems with non-electrified depots, so the point may not matter now.  I know the problem has occurred for me with electrified, but it might have been non-electrified also - sorry, I can't recall for sure.

[dantedarkstar]

The crashes are not common. Today I played with GDI version for over 2 hours I think, before the crash I wrote about happened (when Concorde became available). I don't think it has much to do with in-game time, but more about the new vehicles, lines, etc.

About city cars: OOops ! I sort of forgot that you can change traffic density in-game. Yes, the traffic started to become a bit exagarrated - about half of intercity roads were completely blocked by the queues of cars, occassionally moving one or two tiles. I am going to post something about this AND some passenger routing things in separate thread.
Did you like my Spirals of the Void ?    They suck... (cars out of the road system).

[jamespetts]

Dante,

the spirals of doom are, I think, a rather ingenious, albeit inaesthetic, exploit I shall very much look forward to your other thread. As to the crashes, I really have not been able to track down the problem - but thank you very much for all your information. Perhaps I will get it sooner or later!

[tick tock]

Did you like my Spirals of the Void ?    They suck... (cars out of the road system).

dante -

I had to take at look at your savegame just to see what "spirals" you two were talking about.  Very funny!  (They look rather effective too.)

When you do start a thread about the traffic/congestion I'll be joining in too - I've been meaning to bring this up.

[Colin]

I don't see the problem with 'traffic congestion' either you can set the 'Traffic Density' lower or you can syphon the traffic out of your cities and on to arterial roads, then stop them from returning by using 'No Entry' signs.

[dantedarkstar]

The game just crashed on me again, but this time NOT when I was entering the depot, but when I was removing a bridge. As a public player I built a bridge over human-controlled diagonal railway. Then I decided to change the arrangement a bit and tried to remove the bridge. The game crashed.
I vaguely remember some old version of simutrans crashing when using remove tool you removed the pillars of a bridge (you could do that) and then tried to remove the bridge.

Anyway, I tried to do that again, and this time it crashed when removing the road. And when I started fooling around, a completely weird thing happened, described below (Weird Road Piece).

Anyway, this happened three times when fooling around with a road in-use, while didn't happen when I was working on a new highway (not-in-use, I put roadblocks for building time). Might it be connected to the vehicle routing ? Is convoi routing different in Experimental than in Standard ?

I don't really expect anything to be done about it right now, since the evidence is vague at best. Just putting all the info there is in one place.


Weird road piece
After a moment of fooling around I ended up with UNTOUCHABLE, unremovable piece or road - it was a piece or public road over which a private "private" sign was put, then I upgraded to road with public player. And I couldn't remove either the sign or the road with anyone ! Yay ! And actually it crashed AGAIN quickly (although still not reproducable on demand). The bad thing is I can't create this untouchable thing again - it's one-time thing. Well, I didn't try to reproduce it with the road that is in-use (as the one where it happened was).
Actually, the thing is saveable - saving and reloading doesn't change that. Here is the savegame with the curiosity !
http://simutrans-germany.com/files/upload/Q4_xbad2.sve
In the middle of the map, near Slupsk, just left of the Russian Church there is a road with two private signs one after another. The one closer to the main road is the untouchable road piece (and the other tile of asphalt too it seems).

Having said that, I realize the "unremovable" piece is not Experimental-exclusive "feature" (probably, hard to tell, can't load experimental game into standard and since I can't reproduce the untouchable thing I can't test). It's just something that happened when I was fooling around trying to crash the game.

[jamespetts]

Dante,

I have not altered the convoy routing, or the code for placing or removing roads (other than to check before it is done that there is enough money). Can you check to see whether you can reproduce this on the latest nightly of Simutrans-Standard?

[dantedarkstar]

I can't "reproduce" it even on Experimental.
They are semi-random crashes. Maybe I will try sometime, but next week I'm going for a conference in Rome, so I sort of won't have much time for simutrans 

Anyway, the crashes about roads and the crashes about depots are possibly cause by different things. But it's sort of hard to tell. With a ghost bugs like that, they might be all caused by the same error somewhere on the other end of the code.

[jamespetts]

Dante,

I think that I might have found something relating to the depot crashes, but it is hard to tell, as it is in Knightly's new code (a rare crash on closing a depot window). It might simply have been copied from my code, however. I am not sure what would be causing the newest crashes that you are having, though.

Have a good conference!

[knightly]

James,

I didn't touch any depot related code. Apart from adding goods_catg_index[] and related code to convoi_t, all code that I wrote should be functionally equivalent to the code that I replace, and in some cases fix certain bugs.

Besides, the depot crashes existed even before the introduction of my fixes in v3.12 . Therefore, please investigate carefully before making any premature conclusions.

[jamespetts]

It was not specifically depot related, but line related: the crash that I found occurred in a part of your code that dealt with refreshing the lines, which was invoked when a line window in a depot was closed.

[dantedarkstar]

One extra bit of info about depot-crashes.

This time I started a test on regular pak64 (no timeline), just to look at what's there (mostly play pak128 so don't remember well).
Anyway, I started very small map and then put few ways and depots and looked. In tram depot, I could not buy horses. When I hovered over them, the name and stats were not displayed, clicking on them did nothing. Changing tabs did not help, nor did opening window again or resizing*. After one of the clicks the game crashed.
Maybe it's the same as random crashes when opening depot ? What if somehow the pointers were scrambled enough to not only make thing untargetable, but also crash on retrieving the graphics for the vehicle ?


*why resize ? I noticed that on experimental simutrans, sometimes (randomly) the lowest row of visible vehicles to buy is not correctly "targeted" by the cursor. I mean, when hovering over them nothing is displayed and you can't "click" on them. But resizing the window (doesn't matter if the size actually changed in the end) fixes that. If I remember correctly, if there is more rows than displayed initially and you scroll, the problem also disappears.
I don't remember such behavior in regular simutrans, but then again, I don't really play regular one anymore. I can't guarantee it wasn't the replace window though. Didn't pay that much attention to it. Neither depots nor replaces produce such behavior repeatably.

[Colin]

I've had thr problem with the removal of a bridge, once. I put it down to the CPU not handling the change because I was removing multiple things very quickly, and also have other programs running at the same time. I tried to repeat the crash but could not make it happen again.

[jamespetts]

Thank you both very much for your reports. Unfortunately, as may well be apparent, it is extremely difficult to fix erratic problems such as these, since I need to be able to reproduce the problem in a debugger to have any idea what is going wrong. Whilst I have sometimes experienced the depot window behaving a little oddly with not registering the presence of the mouse cursor, simply moving the cursor downwards a little has always solved that, and I have not had crashes.

Dante and Colin - what operating system are you using? Is it 32- or 64- bit?

[dantedarkstar]

I know that to catch the bug, you have to first locate it. Like I said, I'm just putting every bit of information I get about random crashes here. I do realize they are not enough to find the bug yet.

And I'm still 32-bit.

[jamespetts]

Oops - have I asked that before? Sorry - can be forgetful sometimes :-)

[dantedarkstar]

I don't blame you. After all, it was all in different threads, and you can hardly expect you to remember everybody's system specs.
I am amazed at your forum response rate anyway.

it was 3rd time by the way 

[knightly]

It was not specifically depot related, but line related: the crash that I found occurred in a part of your code that dealt with refreshing the lines, which was invoked when a line window in a depot was closed.

Code that triggers a crash may not be the code that causes the crash.

As for line window in depot, you are talking about the schedule window that pops up when one presses the New Line or Update Line button, right? Can you tell me specifically the part of code you are referring to? And under what circumstances does the crash happen?

[jamespetts]

The code that I added to avoid the crash was:

Code Select Expand


void haltestelle_t::notify_halts_to_rebuild_connexions(const schedule_t *sched,

for (uint8 i = 0; i < entry_count; i++)
{
+ if(welt == NULL)
+ {
+ welt = player->get_welt();
+ }


For some reason, in conditions that I could not reliably recreate, welt would be NULL at that point.

[knightly]

So, you are sure that welt == NULL causes the crashes but not any other thing else? Remember, my code is only added in v3.12, but random crashes are reported since v3.11 .

If crashes are indeed caused by welt == NULL, I have nothing to say . So probably, all member variables need to be explicitly tested for validity before using them.

Anyway, thanks for adding the check for welt == NULL. Hope this can completely resolve the random crashes.

P.S. I am interested to know what code changes the static member variable welt to NULL in the middle of a game. I can't see any reason for doing so, except when loading a game.

[jamespetts]

There was an access violation on a member function of welt. When, in the debugger, I checked welt's value, it was NULL. I do not know why it was NULL in that location, however: that was somewhat mysterious.

[dantedarkstar]

Good news !

I made a test map to see what exactly what trains etc. one could get in pak128. But as a side-effect, I got a highly-probable depot-crash producer !
Whenever I load this save and then just open and close depots, it usually crashes after few times, usually at 3rd. I open and close depot in about 2 seconds and then do the same to another one. Important to "visit" different depots. I used simutrans experimental 3.12 + pure pak128-1.4.5--102.0 (removed the few addons I use for sake of testing). Sometimes it doesn't crash after going through all the depots. But I repeated and after 10 tries it crashed.

Jamespetts, try this to see if you do get the depot crash, and possibly catch the bug ! The maximum work I had to do to crash this save (in about 10 attempts I made) was around 30 clicks.

The map is actually downright silly: 64x64 map with nothing save for row of depots and a bit of way for each. But it "works" (at least for me).
http://simutrans-germany.com/files/upload/test128.sve

[jamespetts]

Dante,

thank you very much for the lead. I tried for about five minutes clicking away at the depots, then tried again for another five minutes with the SDL version, and didn't get a single crash. I can only think that this is a system-specific issue, somehow: but what?

[z9999]

I could confirm crashing.

[tick tock]

I tried it and can consistently get a crash if I open and close the depot windows very quickly.  Especially if I click to open 2 depots in quick succession (without closing the first) and then try to close them very quickly, then it crashes.

However, when doing this at a slower pace, I could not get it to crash.

[jamespetts]

Z9999,

what system do you run?

[dantedarkstar]

I can sometimes get crash even when opening depots at leisure pace. Speed doesn't seem to be critical, although doing it slower makes it harder to get crash.

Anyway, since jamespetts doesn't get the crash (I was afraid that might be the case), we have a really sneaky bug on hands. I don't think I can do it this week, but next week I might try getting source, compiling and trying to catch the bug myself.

[jamespetts]

Dante,

that is very kind of you! That would be much appreciated. Sorry that you've had so much trouble. I very much appreciate your bug fixing efforts...

[Colin]

Dante and Colin - what operating system are you using? Is it 32- or 64- bit?

Hi James I'm using 32bit WINXPSP3.

I've just encountered another random crash. I was attempting to delete a tunnel and it just stopped working with usual error Message.

I'd just like to comment here on another 'Bug'? that was mentioned on a different post. The game goes very laggy, especially after an Auto Save. It can take anything from 25-60 seconds to start responding to Mouse/Keystrokes. Sometimes when you click the mouse or press a key the 'hourglass' will reappear.