[WinSDL r6995] Stopped working error (was: An error here)

[Yona-TYT]

This are the properties of the map.
sim-winsdl r6995
Pak128.Britain r1346


Mod note: please use meaningful topic titles. Make your topic titles descriptive so that readers may know what is in the topic before opening it. Please follow the Bug Reports Guidelines.
~IgorEliezer

[Ters]

We need a little more information than that. What did you do to trigger the error? Or did it just occur spontaneously? The information given by "View problem details" could also be useful in the latter case.

[prissi]

I could not reproduce it. It generated fine for me.

[Yona-TYT]

Watch this video

http://youtu.be/1-lHRbvVFeE

[kierongreen]

Something strange is going on there. You've got an old version of pak128.Britain going by loading screen and strange texture transitions - yet you have half height slopes in it. Also do you have AI enabled?

[Yona-TYT]

Also is present in the pak64 nightly..

[kierongreen]

Again, please try to give more details about what happened.

[Ters]

Looking at the video, it looks like the game crashes when the mouse leaves the window. Either that, or when the mouse passes or clicks on the status bar.

[Yona-TYT]

Other video


http://www.youtube.com/watch?v=ZHsIgjc9XXk

[Ters]

The dialog that the program has crashed tells us nothing. You must click on the "button" at the bottom of the error dialog to show more details.

[Yona-TYT]

The dialog that the program has crashed tells us nothing. You must click on the "button" at the bottom of the error dialog to show more details.

Code Select Expand


Problem signature:
  Problem Event Name: APPCRASH
  Application Name: sim-winsdl.exe
  Application Version: 0.112.4.0
  Application Timestamp: 52be212e
  Fault Module Name: sim-winsdl.exe
  Fault Module Version: 0.112.4.0
  Fault Module Timestamp: 52be212e
  Exception Code: c0000005
  Exception Offset: 0007ed13
  OS Version: 6.2.9200.2.0.0.256.48
  Locale ID: 8202
  Additional Information 1: 55bd
  Additional Information 2: 55bdb125e5f5eebba32ff4470f6d6db1
  Additional Information 3: d8e7
  Additional Information 4: d8e728cfa3b4627b86f2920172200c49

[Ters]

Bummer. The nightlies don't contain debug symbols again. I can't figure out what part of the code is at offset 7ed13.

[kierongreen]

I repeat what I said before - for whatever reason the pak you are using does not contain the correct transitions. pak128.Britain SVN does. You can see the problem on your videos where land is surrounded by water the tile shows random land and water pixels. Is this a problem other people have with nightlies?

[Ters]

If it is transitions, why does it suddenly crash? I would have expected it to either crash upon loading the pak set, or that the crash is preceeded by corrupted images. What was done which triggered the crash? Videos don't show key presses, mouse clicks or mouse wheel scrolling.

[kierongreen]

I agree there's no evidence transitions caused it directly (although they could have caused memory overrun). However it's one thing that is obviously wrong and should be eliminated.

[eipi]

Hm, I did not manage to reproduce the crash reliably, but there seems to be an access violation in pix_alpha_16() (simgraph16.cc, line 3363). The access violation is caused by an invalid (non-NULL) alpha map pointer.
Could this be a threading issue?
Simutrans r6995 and nightly pak128.

Backtrace:

Code Select Expand


> Simutrans-Debug.exe!pix_alpha_16(unsigned short * 0x2176348e, const unsigned short * 0x1fec20bc, const unsigned short * 0x02550000, const unsigned int 0x00000004, const unsigned short 0x224c, const unsigned short 0x002a)  Line 3363 + 0x3 bytes C++
Simutrans-Debug.exe!display_img_alpha_wc(short 0x000a, const short 0x06e0, const short 0x021c, const unsigned short * 0x1fec20a4, const unsigned short * 0x0254ffe8, const unsigned char '', int 0x0000224c, void (unsigned short *, const unsigned short *, const unsigned short *, const unsigned int, const const unsigned short, const const unsigned short)* 0x00689890, const char '')  Line 3507 + 0x3a bytes C++
Simutrans-Debug.exe!display_rezoomed_img_alpha(const unsigned int 0x000052d7, const unsigned int 0x00000000, const unsigned int 0x00000004, short 0x06e0, short 0x021c, const char 0x00, const unsigned short 0x0000, const char 0x00, const int 0x00000000, const char '')  Line 3719 + 0x32 bytes C++
Simutrans-Debug.exe!grund_t::display_boden(const short 0x06e0, const short 0x01ec, const short 0x0060, const char '', const bool false)  Line 1046 + 0x60 bytes C++
Simutrans-Debug.exe!grund_t::display_if_visible(short 0x06e0, short 0x01ec, const short 0x0060, const char '', const bool false)  Line 1206 C++
Simutrans-Debug.exe!karte_ansicht_t::display_region(koord {...}, koord {...}, short 0xfffb, short 0x003a, bool false, bool true, const char '')  Line 373 C++
Simutrans-Debug.exe!karte_ansicht_t::display(bool false)  Line 220 C++
Simutrans-Debug.exe!intr_refresh_display(bool false)  Line 77 C++
Simutrans-Debug.exe!karte_t::sync_step(long 0x00000028, bool true, bool true)  Line 3883 + 0x7 bytes C++
Simutrans-Debug.exe!interrupt_check(const char * 0x00afe0f4)  Line 105 C++
Simutrans-Debug.exe!karte_t::interactive(unsigned int 0x7fffffff)  Line 6752 + 0xa bytes C++
Simutrans-Debug.exe!simu_main(int 0x00000003, char * * 0x02544d90)  Line 1245 C++
Simutrans-Debug.exe!sysmain(const int 0x00000003, char * * const 0x02544d90)  Line 703 + 0xd bytes C++
Simutrans-Debug.exe!WinMain(HINSTANCE__ * const 0x00400000, HINSTANCE__ * 0x00000000, HINSTANCE__ * 0x00000000, HINSTANCE__ * 0x00000000)  Line 725 + 0x16 bytes C++
Simutrans-Debug.exe!main()  Line 691 C++
Simutrans-Debug.exe!__tmainCRTStartup()  Line 555 + 0x19 bytes C
Simutrans-Debug.exe!mainCRTStartup()  Line 371 C
kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes



[IgorEliezer]

Topic renamed. Please use better descriptive topic titles, avoid generic or vague titles. Also, give more details about the occurrence of the bug: http://forum.simutrans.com/index.php?topic=56.0

[Ters]

Hm, I did not manage to reproduce the crash reliably, but there seems to be an access violation in pix_alpha_16() (simgraph16.cc, line 3363). The access violation is caused by an invalid (non-NULL) alpha map pointer.
Could this be a threading issue?

Looks more like the missing transitions kierongreen was suspecting. I just find it a bit surprising that the crash came out of the blue in the first video, but Yona-TYT might have been attempting to do something that doesn't show, if indeed you encounter the same error.

[Yona-TYT]

Topic renamed. Please use better descriptive topic titles, avoid generic or vague titles. Also, give more details about the occurrence of the bug: http://forum.simutrans.com/index.php?topic=56.0

Sorry, but I had no idea what was causing the error, so I chose that title.

And always try to do things the way detailed as possible.

[kierongreen]

The videos actually tend to be very useful.

[Yona-TYT]

I found a way to reproduce the error.


Place the cursor at position (365,93, -1) and zoom out... in this manner.


Use this savegame...http://www.mediafire.com/download/uqn4xnw2d7e1ba9/Yona.sve

[kierongreen]

That definitely suggests something up with graphics routines. Can actually repeat texture errors here just click a new climate and apply it to one tile in water. Unfortunately I'm going to be away from home for over a week now so won't be able to fix it till after then (if someone else doesn't get it first).

[prissi]

I get a strange transition despite being a flat tile. Not sure what the error here.

I think the code need some streamlining in any case, since we cache so much, caching the four corner climatesseems some well invested 16 bit.

[Dwachs]

The problematic thing here is line 1064 in grund.cc, which does alpha blending with animated water tiles. If the animated water tile does not have precisely the same shape as the alpha bitmap then anything weird can occur. A proper solution would be to rewrite the routine display_img_alpha_wc (and maybe other?) to accept images and alpha bitmaps that have different shapes and order of transparent and non-transparent pixels.

This is the same bug as here
http://forum.simutrans.com/index.php?topic=12941.0

[Ters]

I think it might be best to just fail during pak set loading if these images don't match. That makes it easier for the pak set author to detect and fix the error.

[prissi]

But the slope tile is generated by simutrans (it is slope 0, the flat tile), and all pak64 tiles should have exactly the same shape (since they are generated by the same algorithm resp. mask). And special colors are also not involved.

[Dwachs]

Iirc all the animation tiles are not generated but taken from the pak file as they are.

[kierongreen]

The bug also affects pak128.Britain which doesn't have animations. It wasn't there September time for sure but I don't know when the error started.

[prissi]

Ok, but the animations have exactly the same size as the pak64 base tile, and do not have any special colors. I will check this further after the 6th. My laptop here is not up for serious development.

[Yona-TYT]

Watch this ..

[Dwachs]

Here is a patch. It does a careful stepping through the image and the alpha-bitmap. No valgrind complaints anymore. Also pak96.comic shores work again.

Commit?

[Ters]

I'm not sure it's such a good idea to add this to such a performance critical function. If such errors are to be silently ignored, it might be better to just patch the image during start-up.

[Dwachs]

It is not the most performance critical function, it is only called for tiles with transitions between climates. Adjusting images at start-up would mean to create new images for each animation stage and each slope, 81 * #animation sprites.

[prissi]

I still do not understand, why the error occureed with pak64 slopes, which had all the same size. One could of course force the water animation to be of the same size then the flat slope.

[Ters]

How do you get it with pak64?

[Dwachs]

I do not remember exactly, maybe zooming is involved. At least valgrind complains a lot about reads out-of-range in the display_alpha_wc routine, when displaying water animation blended with slope lightmap.

One could of course force the water animation to be of the same size then the flat slope.

The code implicitly assumes already that this is the case. Hence the bug, crashes, and glitches.

[prissi]

This code would only have an impact when zoomed out, because only ten many tiles may need a redraw. Personally I would rather force the water tiles to have the same shape, and otherwise correct it on loadtime. But if there were that many valgrid complains, having a safe routine for now might be the more secure solution.

[Ters]

It's difficult finding out if and why the images don't fit if the only way to see that it happens is by running in valgrind (slow as $@!%), spotting random visual glitches or hoping for a random crash. But Dwachs' patch might at least offer a place to put a breakpoint.

[whoami]

This code would only have an impact when zoomed out, because only ten many tiles may need a redraw.

I use Pak128.Britain (nightly), usually with zoomed out display, and have seen the discussed crash on scrolling four times (the last was with r7003) in several hours of playing.

[Ters]

I've been able to reproduce, if not a crash, then definitively something that's not right. It only affects single tiles of land in the water, which clearly use random data as its mask. Happens predictably and immediately, and affects pak64 and pak128.britain alike. Zooming is not required, although I guess that might eventually lead to a random crash.

From the looks of it, this is not something to gloss over during rendering. Crashes might as well happen when creating the cached rescaled images. We must find the origin of this bug, whether it is in makeobj or simutrans itself.

Update:
When there is a flat one tile island, display_rezoomed_img_alpha gets called with alpha_n=0. I'm not sure what's at images[0], but I'm pretty sure it's not an alpha map for a ground tile. The image in that slot is only 4x4. Another call to display_rezoomed_img_alpha (picked at random) gets an alpha_n corresponding to an image with size 64x17, which sounds right for pak64.

[Ters]

I think the cause chain is as follows:

grund_besch.cc line 585 through 587 causes all_rotations_beach[80] to be left uninitialized.

A flat land tile has corners = 15, which means double_corners on 986 get set to 80. When all_rotations_beach[double_corners] is false, which it likely is since all_rotations_beach[80] was left uninitialized (and it's in static storage), alpha_water_bild[ x] gets left uninitialized for all x corresponding to a flat tile.

This means that when grund.cc calls display_alpha, it passes 0 as alpha_n, which is the image number for a likely completely unrelated image.

[Dwachs]

Thank you very much for this analysis! Revision 7008 now should bring the fix.

The problems with pak96-comic still happen, they need the patch for display_alpha_wc.

[prissi]

Sorry, it seems I was too keen on saving images (and time) when I added the patch to save images.