I have experienced an extremely annoying bug, that's probably very hard to catch (****uming 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.
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.
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.
Tick Tock,
is it, by any chance, confined to electrified depots?
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 (http://simutrans-germany.com/files/upload/Q4_xtmp.sve)
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?
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.
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, occ****ionally moving one or two tiles. I am going to post something about this AND some p****enger routing things in separate thread.
Did you like my Spirals of the Void ? ;D They suck... (cars out of the road system).
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!
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.
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.
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 (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.
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?
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 ;D
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.
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!
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.
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.
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.
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.
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?
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. ;)
Oops - have I asked that before? Sorry - can be forgetful sometimes :-)
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 :P
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?
The code that I added to avoid the crash was:
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.
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 :P. 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.
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.
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 (http://simutrans-germany.com/files/upload/test128.sve)
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?
I could confirm crashing.
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.
Z9999,
what system do you run?
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.
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...
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 'hourgl****' will reappear.
Hi, I just tested dantedarkstars save game on Exp 3.11 with -log 1 -debug 3 on a debian/squeezy 32-bit system; and after opening and closing a few depots the game crashed twice with the following terminal output (memory map of course varies):
*** glibc detected *** /usr/share/games/simutrans/simutrans-exp-latest: corrupted double-linked list: 0x0c6d0050 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xb7cc11e4]
/lib/i686/cmov/libc.so.6[0xb7cc41b2]
/lib/i686/cmov/libc.so.6(__libc_malloc+0x95)[0xb7cc55a5]
/usr/lib/libstdc++.so.6(_Znwj+0x27)[0xb7ebe627]
/usr/lib/libstdc++.so.6(_Znaj+0x1d)[0xb7ebe77d]
/usr/share/games/simutrans/simutrans-exp-latest[0x80cd428]
======= Memory map: ========
08048000-08266000 r-xp 00000000 fe:00 663154 /usr/share/games/simutrans/simutrans-exp-latest
08266000-08267000 rw-p 0021e000 fe:00 663154 /usr/share/games/simutrans/simutrans-exp-latest
08267000-082a9000 rw-p 08267000 00:00 0
08fc9000-0caab000 rw-p 08fc9000 00:00 0 [heap]
b4b00000-b4b21000 rw-p b4b00000 00:00 0
b4b21000-b4c00000 ---p b4b21000 00:00 0
b4cd4000-b4f23000 rw-p b4cd4000 00:00 0
b4f23000-b53c1000 rw-s 00000000 00:08 7929888 /SYSV00000000 (deleted)
b53c1000-b66d4000 rw-p b53c1000 00:00 0
b66d4000-b6739000 rw-p b7287000 00:00 0
b675f000-b67ec000 rw-p b675f000 00:00 0
b67ec000-b67ed000 ---p b67ec000 00:00 0
b67ed000-b6fed000 rw-p b67ed000 00:00 0
b722f000-b7286000 rw-p b7269000 00:00 0
b72a8000-b72d1000 rw-p b72a8000 00:00 0
b72d1000-b72e1000 rw-s 00000000 00:08 6750229 /SYSV0056a4d6 (deleted)
b72e1000-b72eb000 r-xp 00000000 08:02 53894 /lib/i686/cmov/libnss_files-2.9.so
b72eb000-b72ec000 r--p 00009000 08:02 53894 /lib/i686/cmov/libnss_files-2.9.so
b72ec000-b72ed000 rw-p 0000a000 08:02 53894 /lib/i686/cmov/libnss_files-2.9.so
b72ed000-b72f6000 r-xp 00000000 08:02 53900 /lib/i686/cmov/libnss_nis-2.9.so
b72f6000-b72f7000 r--p 00008000 08:02 53900 /lib/i686/cmov/libnss_nis-2.9.so
b72f7000-b72f8000 rw-p 00009000 08:02 53900 /lib/i686/cmov/libnss_nis-2.9.so
b7302000-b7312000 rw-s 00000000 00:0d 5812 /dev/snd/pcmC0D0p
b7312000-b731a000 r-xp 00000000 fe:00 165760 /usr/lib/libXcursor.so.1.0.2
b731a000-b731b000 rw-p 00007000 fe:00 165760 /usr/lib/libXcursor.so.1.0.2
b7321000-b7324000 r-xp 00000000 fe:00 426411 /usr/lib/alsa-lib/libasound_module_rate_speexrate.so
b7324000-b7325000 rw-p 00003000 fe:00 426411 /usr/lib/alsa-lib/libasound_module_rate_speexrate.so
b7325000-b732c000 r-xp 00000000 08:02 53890 /lib/i686/cmov/libnss_compat-2.9.so
b732c000-b732d000 r--p 00006000 08:02 53890 /lib/i686/cmov/libnss_compat-2.9.so
b732d000-b732e000 rw-p 00007000 08:02 53890 /lib/i686/cmov/libnss_compat-2.9.so
b732e000-b7335000 r--s 00000000 fe:00 164219 /usr/lib/gconv/gconv-modules.cache
b7335000-b7535000 r--p 00000000 fe:00 164411 /usr/lib/locale/locale-archive
b7535000-b7538000 rw-p b7535000 00:00 0
b7538000-b753c000 r-xp 00000000 fe:00 164038 /usr/lib/libXdmcp.so.6.0.0
b753c000-b753d000 rw-p 00003000 fe:00 164038 /usr/lib/libXdmcp.so.6.0.0
b753d000-b753f000 r-xp 00000000 fe:00 164712 /usr/lib/libXau.so.6.0.0
b753f000-b7540000 rw-p 00001000 fe:00 164712 /usr/lib/libXau.so.6.0.0
b7540000-b7552000 r-xp 00000000 08:02 53711 /lib/i686/cmov/libresolv-2.9.so
b7552000-b7553000 r--p 00011000 08:02 53711 /lib/i686/cmov/libresolv-2.9.so
b7553000-b7554000 rw-p 00012000 08:02 53711 /lib/i686/cmov/libresolv-2.9.so
b7554000-b7556000 rw-p b7554000 00:00 0
b7556000-b756b000 r-xp 00000000 08:02 53896 /lib/i686/cmov/libnsl-2.9.so
b756b000-b756c000 r--p 00014000 08:02 53896 /lib/i686/cmov/libnsl-2.9.so
b756c000-b756d000 rw-p 00015000 08:02 53896 /lib/i686/cmov/libnsl-2.9.so
b756d000-b756f000 rw-p b756d000 00:00 0
b756f000-b757c000 r-xp 00000000 fe:00 164106 /usr/lib/libXext.so.6.4.0
b757c000-b757d000 rw-p 0000c000 fe:00 164106 /usr/lib/libXext.so.6.4.0
b757d000-b757e000 rw-p b757d000 00:00 0
b757e000-b7581000 r-xp 00000000 08:02 32598 /lib/libuuid.so.1.2
b7581000-b7582000 rw-p 00002000 08:02 32598 /lib/libuuid.so.1.2
b7582000-b759a000 r-xp 00000000 fe:00 166658 /usr/lib/libxcb.so.1.1.0
b759a000-b759b000 rw-p 00017000 fe:00 166658 /usr/lib/libxcb.so.1.1.0
b759b000-b75d6000 r-xp 00000000 08:02 32628 /lib/libncursesw.so.5.7
b75d6000-b75d9000 rw-p 0003b000 08:02 32628 /lib/libncursesw.so.5.7
b75d9000-b75de000 r-xp 00000000 fe:00 164861 /usr/lib/libgpm.so.2.0.0
b75de000-b75df000 rw-p 00004000 fe:00 164861 /usr/lib/libgpm.so.2.0.0
b75df000-b7677000 r-xp 00000000 08:02 32634 /lib/libslang.so.2.1.3
b7677000-b7687000 rw-p 00097000 08:02 32634 /lib/libslang.so.2.1.3
b7687000-b76be000 rw-p b7687000 00:00 0
b76be000-b76ee000 r-xp 00000000 08:02 33114 /lib/libncurses.so.5.7
b76ee000-b76f1000 rw-p 0002f000 08:02 33114 /lib/libncurses.so.5.7
b76f1000-b76f3000 r-xp 00000000 08:02 32636 /lib/libx86.so.1
b76f3000-b76f4000 rw-p 00001000 08:02 32636 /lib/libx86.so.1
b76f4000-b76f9000 r-xp 00000000 fe:00 165034 /usr/lib/libgdbm.so.3.0.0
b76f9000-b76fa000 rw-p 00004000 fe:00 165034 /usr/lib/libgdbm.so.3.0.0
b76fa000-b76fd000 r-xp 00000000 08:02 33112 /lib/libcap.so.2.16
b76fd000-b76fe000 rw-p 00002000 08:02 33112 /lib/libcap.so.2.16
b76fe000-b7734000 r-xp 00000000 fe:00 164386 /usr/lib/libdbus-1.so.3.4.0
b7734000-b7736000 rw-p 00036000 fe:00 164386 /usr/lib/libdbus-1.so.3.4.0
b7736000-b7737000 rw-p b7736000 00:00 0
b7737000-b773b000 r-xp 00000000 fe:00 165679 /usr/lib/libasyncns.so.0.1.0
b773b000-b773c000 rw-p 00003000 fe:00 165679 /usr/lib/libasyncns.so.0.1.0
b773c000-b7743000 r-xp 00000000 08:02 32762 /lib/libwrap.so.0.7.6
b7743000-b7744000 rw-p 00007000 08:02 32762 /lib/libwrap.so.0.7.6
b7744000-b7748000 r-xp 00000000 fe:00 165337 /usr/lib/libXtst.so.6.1.0
b7748000-b7749000 rw-p 00003000 fe:00 165337 /usr/lib/libXtst.so.6.1.0
b7749000-b7750000 r-xp 00000000 fe:00 164340 /usr/lib/libSM.so.6.0.0
b7750000-b7751000 rw-p 00006000 fe:00 164340 /usr/lib/libSM.so.6.0.0
b7751000-b7766000 r-xp 00000000 fe:00 164137 /usr/lib/libICE.so.6.3.0
b7766000-b7767000 rw-p 00014000 fe:00 164137 /usr/lib/libICE.so.6.3.0
b7767000-b7769000 rw-p b7767000 00:00 0
b7769000-b7883000 r-xp 00000000 fe:00 164273 /usr/lib/libX11.so.6.2.0
b7883000-b7887000 rw-p 00119000 fe:00 164273 /usr/lib/libX11.so.6.2.0
b7887000-b7888000 rw-p b7887000 00:00 0
b7888000-b78cb000 r-xp 00000000 fe:00 166928 /usr/lib/libpulsecommon-0.9.15.so
b78cb000-b78cc000 rw-p 00043000 fe:00 166928 /usr/lib/libpulsecommon-0.9.15.so
b78cc000-b78ec000 r-xp 00000000 fe:00 165069 /usr/lib/libaudiofile.so.0.0.2
b78ec000-b78ef000 rw-p 0001f000 fe:00 165069 /usr/lib/libaudiofile.so.0.0.2
b78ef000-b78f6000 r-xp 00000000 08:02 53899 /lib/i686/cmov/librt-2.9.so
b78f6000-b78f7000 r--p 00006000 08:02 53899 /lib/i686/cmov/librt-2.9.so
b78f7000-b78f8000 rw-p 00007000 08:02 53899 /lib/i686/cmov/librt-2.9.so
b78f8000-b790d000 r-xp 00000000 08:02 53927 /lib/i686/cmov/libpthread-2.9.so
b790d000-b790e000 r--p 00014000 08:02 53927 /lib/i686/cmov/libpthread-2.9.so
b790e000-b790f000 rw-p 00015000 08:02 53927 /lib/i686/cmov/libpthread-2.9.so
b790f000-b7911000 rw-p b790f000 00:00 0
b7911000-b792d000 r-xp 00000000 fe:00 165687 /usr/lib/libcaca.so.0.99.16
b792d000-b79b4000 rw-p 0001b000 fe:00 165687 /usr/lib/libcaca.so.0.99.16
b79b4000-b79ba000 rw-p b79b4000 00:00 0
b79ba000-b79d2000 r-xp 00000000 fe:00 166799 /usr/lib/libaa.so.1.0.4
b79d2000-b79d4000 rw-p 00018000 fe:00 166799 /usr/lib/libaa.so.1.0.4
b79d4000-b79d5000 rw-p b79d4000 00:00 0
b79d5000-b7a26000 r-xp 00000000 fe:00 164911 /usr/lib/libvga.so.1.4.3
b7a26000-b7a2d000 rw-p 00050000 fe:00 164911 /usr/lib/libvga.so.1.4.3
b7a2d000-b7a36000 rw-p b7a2d000 00:00 0
b7a36000-b7a4c000 r-xp 00000000 fe:00 166166 /usr/lib/libdirect-1.2.so.0.7.0
b7a4c000-b7a4d000 rw-p 00016000 fe:00 166166 /usr/lib/libdirect-1.2.so.0.7.0
b7a4d000-b7a55000 r-xp 00000000 fe:00 166168 /usr/lib/libfusion-1.2.so.0.7.0
b7a55000-b7a56000 rw-p 00007000 fe:00 166168 /usr/lib/libfusion-1.2.so.0.7.0
b7a56000-b7acc000 r-xp 00000000 fe:00 165092 /usr/lib/libdirectfb-1.2.so.0.7.0
b7acc000-b7acf000 rw-p 00075000 fe:00 165092 /usr/lib/libdirectfb-1.2.so.0.7.0
b7acf000-b7b1b000 r-xp 00000000 fe:00 165326 /usr/lib/libXt.so.6.0.0
b7b1b000-b7b1e000 rw-p 0004c000 fe:00 165326 /usr/lib/libXt.so.6.0.0
b7b1e000-b7b20000 rw-p b7b1e000 00:00 0
b7b20000-b7b35000 r-xp 00000000 fe:00 165219 /usr/lib/libaudio.so.2.4
b7b35000-b7b36000 rw-p 00015000 fe:00 165219 /usr/lib/libaudio.so.2.4
b7b36000-b7b70000 r-xp 00000000 fe:00 166926 /usr/lib/libpulse.so.0.8.0
b7b70000-b7b71000 rw-p 0003a000 fe:00 16Avbruten (SIGABRT)
Furthermore it crashed yet another time with no console output apart from Segfault. So there might be more than one issue involved (or not?)
Hope this does not add to the confusion... I will retest the game with latest Exp as soon as I have time to upgrade to it *smile*
EDIT: Just tested it with Exp 3.12, and the same behavior (crashing with: *** glibc detected *** /usr/share/games/simutrans/simutrans-exp-latest: corrupted double-linked list: 0x0beb45e0 ***) occurs.
I don't think that is important.
In my case, this step cause crash. 100% reproducible for me.
1. Open left side train depot window.
2. Open right side train depot window.
3. Close right side train depot window.
4. Open monorail depot window.
James,
I have found another problem : after many trials of opening and closing depots in Dante's save game, even if the game hasn't crash yet, clicking either "Load" or "Save" button in the main menu will crash the game immediately.
I have tried to reproduce the crashes in debug mode and debug builds, but not successful so far. I suspect the bug has something to do with the difference between debug and release builds.
I have had a bug where I updated a rail depot to take electricity, and when I clicked on the electric locomotives, it crashed.
Also, the auto rail signal thing is quite buggy, if you click on a single bit of rail with ctrl held down, then that persistently seems to crash the game. Both of these are with 3.12.
Thanks
Mastone,
thank you for your bug reports. I shall look into those when I can, although I suspect that I will have difficulties reproducing the issue with the depot. As to the issue with the automatic signal placement tool, was that the only problem that you had with it? Thank you again for your bug reports, and thank you also for your interest in Simutrans-Experimental :-)
Edit: I have now found and fixed the problem with the signal placement tool, but cannot, I am afraid, reproduce the issue with the depot.
Edit 2: I have, however, been able to reproduce the original depot crash with the wintry save game provided above with the release version of 3.12, but not a release build (tested with the debugger engaged) of the proto 3.13. I have no idea whether that means that I have inadvertently fixed the problem, but I should be grateful if people could test when the final 3.13 comes out.
James,
As I have mentioned above, when testing in debug mode (i.e. with debugger enabled), regardless of whether it is a release build or debug build, it seems to be impossible to reproduce the crashes. I don't know why it is like that, but that is what I realised from my tests on v3.12
So, please test the release build of v3.13 again without the debugger.
P.S. Can you release v3.13 first without waiting for fixing the crashes? I am afraid that the bug which causes the crashes is not catchable in a debugger. Besides, I would like to know if my patch truly fixes the lagginess. Thanks!
I would second that because it is now impossible to play the game at my level, not because of crashes I hasten to add, I don't get
them often enough to be a worry, but because the freeze up has now extended to 7-9 Simu Days. (I'm now forced to play The Godfather II on line with one or more of my grandchildren. HELP!!!)LOL
Sorry for this completely off-topic post, but after looking up Colin's profile I must say I'm deeply impressed - I really hope I'll be as young in mind and open to new technologies at your age as you are! Hats off!
Knightly,
thank you for spotting that the issue is not with the differences between the debug/release builds, per se, but between running it in a debugger and running it stand-alone. I have indeed been able to reproduce the crashes in a stand-alone build. This is a very strange problem indeed, and enormously difficult to track down without the aid of a debugger, especially as the error is intermittent, not deterministic. I have not been able to solve this for 3.13, unfortunately.
However, 3.13 does now incorporate all of the optimisations to the routing, which should deal with the performance issues reported. Also, the crash when holding down CTRL when using automatic signals is fixed.
Well not quite so young in mind as you put it, but I've been using computers since Tandy or Radio Shack brought out their first TRS80/Z80. Remember that if you can. LOL.
Today, I got a curious thing. During game, the screen got completely "jammed". It originated from one tile (when I moved away it was gone, when I moved to the location it was back). Shortly after the game crashed.
These symptoms in my book mean that the cause of these crashes is some pointer mixup or unchecked index out of bounds. It's bad news since these type of bugs could be practically anywhere in the code.
The appearance of parts of the sand quarry in the jammed part would point to pointer mixup - like if simutrans was trying to get graphics from a wrong place in memory. Maybe usually when this happens it's outside simutrans and immediately produces error that the memory cannot be read, but this one time he accidentally hit somewhere within simutrans and could therefore read ?
Here's the screenshot in question:
(http://img30.imageshack.us/img30/8123/simscr25.th.png) (http://img30.imageshack.us/my.php?image=simscr25.png)
Ohh, dear. That sort of error is extremely hard to debug. Can you upload a saved game?
I can, but it won't help. After I started game again and loaded the save (it was by coincidence saved just a few moments before this occured) the jam didn't appear again. The "seemingly random" seems to be "really quasi-random". I just wanted to share a rare observation that might be or might be not really related to the issue at hand.
What I will have to do is to try compiling the simutrans-experimental on watcom and see if the same error occurs. Because if it doesn't, it may be either the VC or just some intricate interference between the current code and VC routines. Anyway, tomorrow or on saturday I will try that out.
Dante,
that's very kind! Thank you.
Well, I tried my first compilation but I failed big time. Errors started popping from the very first file to be compiled :(
But I'll be asking on the main simutrans development forum since it has nothing to do with your code (I looked and the same thing is in standard simutrans).
It might take some time before I succesfully compile that beast :-\
Ahh, sorry that you've had problems. Are you 64-bit? I know that people have had trouble with that, although I thought that Prissi fixed it a while back.
No, I'm 32 bit. It's because of the compiler (additionally I'm not familiar with Watcom). I get strange errors that result from the code not being suited for Watcom (defines that make compiler error out, unexplained ignorance of what "abs" is etc.). I solved few of them but got tired out by some more complicated now on the plate. Will pick it up tomorrow... err... today morning/afternoon.
Thank you very much for your efforts - very best wishes in getting it working!