Crash on "Reset zoom" bzr9005-201903031251 (Release)

[HH King]

Was zoomed in, hit the "Reset zoom" button - freeze, crash.

Running Kubuntu 18.04
$ widelands
This is Widelands Version bzr9005-201903031251 (Release)
# many lines...
Fatal exception: std::bad_alloc
FATAL ERROR - game crashed. Attempting emergency save.
Game: Writing Preload Data ...
[1]+ Segmentation fault (core dumped) widelands

[kaputtnik (franku)]

Thanks for your bugreport.

I can't reproduce this though. Either in release or in debug builds.

Does this happen again?

Did you had any other windows open?

Can you provide a save game?

[HH King (havelock)]

It has happened a couple of times. Maybe a coincidence with the zoom. I had Firefox and a terminal open as well as Widelands (not fullscreen. I'm sorry I do not have the saved game but it didn't crash when played. Perhaps I'll compile a more debuggable version and see if I catch it again.

Probably not too helpfull but:
(gdb) bt full
#0 0x000055619fd7893f in Widelands::GamePreloadPacket::write(FileSystem&, Widelands::Game&, Widelands::MapObjectSaver*) ()
No symbol table info available.
#1 0x000055619fd78fd2 in Widelands::GameSaver::save() ()
No symbol table info available.
#2 0x000055619fac7c1b in ?? ()
No symbol table info available.
#3 0x000055619fcc49f4 in GenericSaveHandler::save_file() ()
No symbol table info available.
#4 0x000055619fcc4d88 in GenericSaveHandler::save() ()
No symbol table info available.
#5 0x000055619fac878f in SaveHandler::save_game(Widelands::Game&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) ()
No symbol table info available.
#6 0x000055619f9e34c8 in WLApplication::emergency_save(Widelands::Game&) ()
No symbol table info available.
#7 0x000055619f9e6c4c in WLApplication::load_game() ()
No symbol table info available.
#8 0x000055619f9e845f in WLApplication::mainmenu_singleplayer() ()
No symbol table info available.
#9 0x000055619f9e8860 in WLApplication::mainmenu() ()
No symbol table info available.
#10 0x000055619f9e8e17 in WLApplication::run() ()
No symbol table info available.
#11 0x000055619f999eac in main ()
No symbol table info available.

[HH King (havelock)]

To clarify, I played the autosaved game - the emergency save did not happen.

[kaputtnik (franku)]

With 'windows' i meant any window inside the game, e.g. Notifications or buildings statistic ;)

So this bug appears randomly for you?
Do you remember if the map was big? E.g. a map for 8 players

[GunChleoc (gunchleoc)]

The problem with the analysis here is that the emergency save is hiding the real backtrace in GDB.

Can you try reproducing this in the editor?

[HH King (havelock)]

OK in the editor was zoomed out, hit the Reset zoom button and got a crash. I have had it crash ingame as well but with the same uninteresting bt as above. This is from the editor crash:

$ gdb -batch -ex "run" -ex "bt" ./widelands >> gdb.log 2>&1

This is Widelands Version bzr9006[widelands] (Debug)
...
 MapSaver::save() for 'After the Wood Gnomes' took 659ms
atlanteans trainingsites: We have used up 100% on 2 sites, there are 0 without
barbarians trainingsites: We have used up 100% on 2 sites, there are 0 without
empire trainingsites: We have used up 100% on 3 sites, there are 0 without
frisians trainingsites: We have used up 100% on 2 sites, there are 0 without
terminate called after throwing an instance of 'std::length_error'
  what(): vector::_M_default_append

Thread 1 "widelands" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff5309801 in __GI_abort () at abort.c:79
#2 0x00007ffff5cfc8b7 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3 0x00007ffff5d02a06 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4 0x00007ffff5d02a41 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5 0x00007ffff5d02c74 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6 0x00007ffff5cfe769 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00005555565ea469 in std::vector<FieldsToDraw::Field, std::allocator<FieldsToDraw::Field> >::_M_check_len (this=0x55556b1b6148, __n=18446744072217781287, __s=0x5555568bbaf6 "vector::_M_default_append") at /usr/include/c++/7/bits/stl_vector.h:1500
#8 0x00005555565ea194 in std::vector<FieldsToDraw::Field, std::allocator<FieldsToDraw::Field> >::_M_default_append (this=0x55556b1b6148, __n=18446744072217781287) at /usr/include/c++/7/bits/vector.tcc:568
#9 0x00005555565ea0ad in std::vector<FieldsToDraw::Field, std::allocator<FieldsToDraw::Field> >::resize (this=0x55556b1b6148, __new_size=18446744072217791297) at /usr/include/c++/7/bits/stl_vector.h:692
#10 0x00005555565e96f0 in FieldsToDraw::reset (this=0x55556b1b6130, egbase=..., viewpoint=..., zoom=-922624, dst=0x555560e67d90) at /home/worm/src/widelands/src/graphic/gl/fields_to_draw.cc:111
#11 0x00005555565d1dc8 in MapView::draw_terrain (this=0x55556b1b6018, egbase=..., dst=0x555560e67d90) at /home/worm/src/widelands/src/wui/mapview.cc:380
#12 0x0000555555f30204 in EditorInteractive::draw (this=0x55556b1b5f10, dst=...) at /home/worm/src/widelands/src/editor/editorinteractive.cc:265
#13 0x0000555556269910 in UI::Panel::do_draw_inner (this=0x55556b1b5f10, dst=...) at /home/worm/src/widelands/src/ui_basic/panel.cc:751
#14 0x0000555556269aea in UI::Panel::do_draw (this=0x55556b1b5f10, dst=...) at /home/worm/src/widelands/src/ui_basic/panel.cc:784
#15 0x0000555556268346 in UI::Panel::do_run (this=0x55556b1b5f10) at /home/worm/src/widelands/src/ui_basic/panel.cc:194
#16 0x0000555555f163c8 in UI::Panel::run<UI::Panel::Returncodes> (this=0x55556b1b5f10) at /home/worm/src/widelands/src/ui_basic/panel.h:103
#17 0x00...

[GunChleoc (gunchleoc)]

This is really weird. The lines are:

109 const size_t dimension = w_ * h_;
110 if (fields_.size() != dimension) {
111 fields_.resize(dimension);
112 }

The crash is in line 111. The fields_ vector can't be invalid, because otherwise line 110 would have crashed. It still doesn't want to be resized though.

I have tried loading maps of different sizes and zooming out and resetting and could not trigger this on Linux Mint. Time to try the ppa.

[HH King (havelock)]

I can never trigger it when I'm trying :) Usually I give up and play/edit for a couple hours (but with lots of zooming) before it hits. I have an impression that it is more likely when zoomed all the way out, then reset but there's not enough data to say.

[GunChleoc (gunchleoc)]

I think I understand the problem now - Widelands doesn't have enough memory allocated to grow the vector to the required size. So, I have added a safeguard there in the attached branch, which will log to console when there isn't enough memory and then simply not update the additional fields. You will see fields not properly drawn/updated at the bottom of the screen then.

It's actually a vital hint that this happens only after a long time -> I found that the editor's "Undo" stack is unlimited, so I am putting a cap on that. I think 500 undo actions should be sufficient for anybody.

For in-game memory, I guess we'll need to do some profiling, because I don't know what is constantly growing at this point. LeakSanitizer is reporting some memory leaks in the scripting component, but we have not been able to resolve those yet.

[GunChleoc (gunchleoc)]

I have created a merge request that will hopefully fix the issue for the editor.

Do you still have an autosave from one of the crashed games?

[Klaus Halfmann (klaus-halfmann)]

Nice Map, please consider uploading this one to https://wl.widelands.org/maps/

I will try to reproduce this withh another "Continent" and some Islands or such :-)

[Klaus Halfmann (klaus-halfmann)]

OK, I found a +/- related bug at #1819311. Looks llike we need to do more things with big maps.

[HH King (havelock)]

As requested, here's the last autosave before a crash. Was zoomed all the way out and hit reset.

This is Widelands Version bzr9006[widelands] (Debug)
...
Fatal exception: vector::_M_default_append
FATAL ERROR - game crashed. Attempting emergency save.

[GunChleoc (gunchleoc)]

Thanks!

I didn't get a crash from this, but the zoom stopped working after a bit

[kaputtnik (franku)]

> but the zoom stopped working after a bit

I can reproduce this with every map in the editor by holding down CTRL + - for a while until zooming stops. Just start the editor and hold down CTRL + - until zooming stops. CTRL + 0 and the mouse wheel does not work for zooming then, but holding down CTRL + + for a while do work.

[GunChleoc (gunchleoc)]

I have found the problem with #14/#15 https://code.launchpad.net/~gunchleoc/widelands/bug-1818494-ingame-zoom-freezes/+merge/364304

[GunChleoc (gunchleoc)]

I have had a look at our memory usage with valgrind. After an initial memory spike ~250 MB when loading the game, the memory usage drops again and keeps pretty stable. When zooming out, animations start taking up a lot more memory, followed by the terrain program.

I'll investigate if we can save some memory here without sacrificing performance. If the fix gets too complicated, I'll postpone it until after Build 20.

@HH King thank you very much for reporting, this really helped us to improve things. For now, don't zoom out too much in long games if you have a big screen.

[GunChleoc (gunchleoc)]

Fix is too involved, so I am postponing this.

One of our bottlenecks is that we always load all sound effects into memory - I have attached a branch that will load them only on demand. This helps with the big memory spike when the game is being initialized, but probably doesn't make much of a difference later in the game.

[HH King (havelock)]

I recalled that the first time I crashed the program I was zoomed in and hit reset. I made a smaller map and tried to crash it again like that. Sure enough...

This is Widelands Version bzr9006[widelands] (Debug)
...
TrainingSite::drop_stalled_soldiers: Kicking somebody out.
Fatal exception: std::bad_alloc
FATAL ERROR - game crashed. Attempting emergency save.
Game: Writing Preload Data ...
Thread 1 "widelands" received signal SIGSEGV, Segmentation fault.

So I'm wondering if there are two issues, the zoomed out crash/stall and the original zoomed in reset. I'll try and get it in the editor so I can get a usefull bt.

[HH King (havelock)]

This is zoomed out and hit reset (this might be already fixed in 9024? but since there's an assert I thought it might be helpfull.)

This is Widelands Version bzr9023[widelands] (Debug)
...
4: Ullr: new island exploration - direction: 2
TrainingSite::drop_stalled_soldiers: Kicking somebody out.
widelands: /home/worm/src/widelands/src/graphic/gl/fields_to_draw.cc:109: void FieldsToDraw::reset(const Widelands::EditorGameBase&, const Vector2f&, float, RenderTarget*): Assertion `w_ > 0' failed.

Thread 1 "widelands" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff5307801 in __GI_abort () at abort.c:79
#2 0x00007ffff52f739a in __assert_fail_base (fmt=0x7ffff547e7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5555568c1516 "w_ > 0", file=file@entry=0x5555568c1488 "/home/worm/src/widelands/src/graphic/gl/fields_to_draw.cc", line=line@entry=109, function=function@entry=0x5555568c1640 <FieldsToDraw::reset(Widelands::EditorGameBase const&, Vector2<float> const&, float, RenderTarget*)::__PRETTY_FUNCTION__> "void FieldsToDraw::reset(const Widelands::EditorGameBase&, const Vector2f&, float, RenderTarget*)") at assert.c:92
#3 0x00007ffff52f7412 in __GI___assert_fail (assertion=0x5555568c1516 "w_ > 0", file=0x5555568c1488 "/home/worm/src/widelands/src/graphic/gl/fields_to_draw.cc", line=109, function=0x5555568c1640 <FieldsToDraw::reset(Widelands::EditorGameBase const&, Vector2<float> const&, float, RenderTarget*)::__PRETTY_FUNCTION__> "void FieldsToDraw::reset(const Widelands::EditorGameBase&, const Vector2f&, float, RenderTarget*)") at assert.c:101
#4 0x00005555565eed96 in FieldsToDraw::reset (this=0x55555f22c0d0, egbase=..., viewpoint=..., zoom=-922624, dst=0x55555ecaef90) at /home/worm/src/widelands/src/graphic/gl/fields_to_draw.cc:109
#5 0x00005555565d7496 in MapView::draw_terrain (this=0x55555f22bfb8, egbase=..., dst=0x55555ecaef90) at /home/worm/src/widelands/src/wui/mapview.cc:380
#6 0x000055555631f9fc in InteractivePlayer::draw_map_view (this=0x55555f22beb0, given_map_view=0x55555f22bfb8, dst=0x55555ecaef90) at /home/worm/src/widelands/src/wui/interactive_player.cc:291
#7 0x000055555631f8e3 in InteractivePlayer::draw (this=0x55555f22beb0, dst=...) at /home/worm/src/widelands/src/wui/interactive_player.cc:278
#8 0x000055555626e65c in UI::Panel::do_draw_inner (this=0x55555f22beb0, dst=...) at /home/worm/src/widelands/src/ui_basic/panel.cc:751
#9 0x000055555626e836 in UI::Panel::do_draw (this=0x55555f22beb0, dst=...) at /home/worm/src/widelands/src/ui_basic/panel.cc:784
#10 0x000055555626d092 in UI::Panel::do_run (this=0x55555f22beb0) at /home/worm/src/widelands/src/ui_basic/panel.cc:194
#11 0x0000555555f1925c in UI::Panel::run<UI::Panel::Returncodes> (this=0x55555f22beb0) at /home/worm/src/widelands/src/ui_basic/panel.h:103
#12 0x0000555556065dce in Widelands::Game::run (this=0x7fffffff9ac0, loader_ui=0x7fffffff97c0, start_game_type=Widelands::Game::Loaded, script_to_run="", replay=false, prefix_for_replays="...

[GunChleoc (gunchleoc)]

Thanks, that certainly helps. Screen resolution might also be a factor, which resolution are you using?

[GunChleoc (gunchleoc)]

I have attached a branch that will produce lots of log output for that function. I don't understand yet why it can become < 0, so it would be good to see your numbers when it crashes.

If all else fails, we could add a hotfix for Build 20 that will simply skip the rest of the function if the dimension is <= 0.

[HH King (havelock)]

Screen resolution is 1280x720.

[GunChleoc (gunchleoc)]

I still can't reproduce this *headdesk*. Would you like to try compiling the branch with the log output, hoping that we get more useful info from there?

https://code.launchpad.net/~widelands-dev/widelands/bug-1818494-fieldstodraw-assert

This is what you need to do:

sudo apt install bzr cmake g++ gcc gettext libboost-dev libboost-regex-dev libboost-system-dev libboost-test-dev libglew-dev libpng-dev libsdl2-dev libsdl2-image-dev libsdl2-mixer-dev libsdl2-ttf-dev python zlib1g-dev

bzr branch lp:~widelands-dev/widelands/bug-1818494-fieldstodraw-assert
cd bug-1818494-fieldstodraw-assert
./compile.sh -w

More instructions:
https://wl.widelands.org/wiki/BzrPrimer/
https://wl.widelands.org/wiki/BuildingWidelands/#ubuntu-debian

[kaputtnik (franku)]

Since no one can reproduce, this might a hardware problem? E.g. a Ram block is damaged?

Can you post the output of

free -h

Anyway it would be interesting if the bug is still there for you when running the last development build.

[GunChleoc (gunchleoc)]

It is still there - I added the assert that was triggered in #20 with my other fixes related to this branch. So, that assert could never have been triggered with an older version.

The crash happens because the dimension of the viewport to show goes negative. It does not seem to be a simple int overflow though, because I can run it even at higher resolutions without a problem.

If we can't figure this out soon, we can hack it for Build 20 and simply skip the rest of the function if the dimension goes negative, but I'd rather have a real fix.

[kaputtnik (franku)]

uups... overlooked that this was r9023.

[HH King (havelock)]

Big map and 14h run time before I finally hit this. I'm going to figure out how to run memtest - been a decade or so since I used it :)

This is Widelands Version bzr9025[bug-1818494-fieldstodraw-assert] (Debug)
...
NOCOM br_map (19162.43, 5214.09)
NOCOM min_f (219, 72), max_f (300, 163)
NOCOM adjusted min_f (217, 70), max_f (302, 173)
NOCOM w, h (86, 104)
**************************
NOCOM viewpoint (14042.43, 2334.09), zoom: 4.00
NOCOM dst (0, 0, 1280, 720)
NOCOM br_map (19162.43, 5214.09)
NOCOM min_f (219, 72), max_f (300, 163)
NOCOM adjusted min_f (217, 70), max_f (302, 173)
NOCOM w, h (86, 104)
**************************
NOCOM viewpoint (14042.43, 2334.09), zoom: 4.00
NOCOM dst (0, 0, 1280, 720)
NOCOM br_map (19162.43, 5214.09)
NOCOM min_f (219, 72), max_f (300, 163)
NOCOM adjusted min_f (217, 70), max_f (302, 173)
NOCOM w, h (86, 104)
**************************
NOCOM viewpoint (6144.00, 0.00), zoom: -922624.00
NOCOM dst (0, 0, 1280, 720)
NOCOM br_map (-1180952576.00, -664289280.00)
NOCOM min_f (96, 0), max_f (-18452384, -20759040)
NOCOM adjusted min_f (94, -2), max_f (-18452382, -20759030)
NOCOM w, h (-18452475, -20759027)
widelands: /home/worm/src/test/bug-1818494-fieldstodraw-assert/src/graphic/gl/fields_to_draw.cc:123: void FieldsToDraw::reset(const Widelands::EditorGameBase&, const Vector2f&, float, RenderTarget*): Assertion `w_ > 0' failed.

Thread 1 "widelands" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007ffff5307801 in __GI_abort () at abort.c:79
#2 0x00007ffff52f739a in __assert_fail_base (fmt=0x7ffff547e7d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5555568c513c "w_ > 0", file=file@entry=0x5555568c4f98 "/home/worm/src/test/bug-1818494-fieldstodraw-assert/src/graphic/gl/fields_to_draw.cc", line=line@entry=123, function=function@entry=0x5555568c5280 <FieldsToDraw::reset(Widelands::EditorGameBase const&, Vector2<float> const&, float, RenderTarget*)::__PRETTY_FUNCTION__> "void FieldsToDraw::reset(const Widelands::EditorGameBase&, const Vector2f&, float, RenderTarget*)") at assert.c:92
#3 0x00007ffff52f7412 in __GI___assert_fail (assertion=0x5555568c513c "w_ > 0", file=0x5555568c4f98 "/home/worm/src/test/bug-1818494-fieldstodraw-assert/src/graphic/gl/fields_to_draw.cc", line=123, function=0x5555568c5280 <FieldsToDraw::reset(Widelands::EditorGameBase const&, Vector2<float> const&, float, RenderTarget*)::__PRETTY_FUNCTION__> "void FieldsToDraw::reset(const Widelands::EditorGameBase&, const Vector2f&, float, RenderTarget*)") at assert.c:101
#4 0x00005555565ef42e in FieldsToDraw::reset (this=0x5555587b67b0, egbase=..., viewpoint=..., zoom=-922624, dst=0x5555585f0650) at /home/worm/src/test/bug-1818494-fieldstodraw-assert/src/graphic/gl/fields_to_draw.cc:123
#5 0x00005555565d7686 in MapView::draw_terrain (this=0x5555587b6698, egbase=..., dst=0x5555585f0650) at /home/worm/src/test/bug-1818494-fieldstodraw-assert/src/wui/mapview.cc:380
#6 0x000055555631fbec in Inter...

[HH King (havelock)]

Well no obvious memory problem:

$ free -h
              total used free shared buff/cache available
Mem: 7.7G 385M 6.7G 38M 623M 7.0G
Swap: 2.0G 0B 2.0G
$ sudo memtester 7G 2
memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 7168MB (7516192768 bytes)
got 7168MB (7516192768 bytes), trying mlock ...locked.
Loop 1/2:
  Stuck Address : ok
  Random Value : ok
  Compare XOR : ok
  Compare SUB : ok
  Compare MUL : ok
  Compare DIV : ok
  Compare OR : ok
  Compare AND : ok
  Sequential Increment: ok
  Solid Bits : ok
  Block Sequential : ok
  Checkerboard : ok
  Bit Spread : ok
  Bit Flip : ok
  Walking Ones : ok
  Walking Zeroes : ok
  8-bit Writes : ok
  16-bit Writes : ok

Loop 2/2:
  Stuck Address : ok
  Random Value : ok
  Compare XOR : ok
  Compare SUB : ok
  Compare MUL : ok
  Compare DIV : ok
  Compare OR : ok
  Compare AND : ok
  Sequential Increment: ok
  Solid Bits : ok
  Block Sequential : ok
  Checkerboard : ok
  Bit Spread : ok
  Bit Flip : ok
  Walking Ones : ok
  Walking Zeroes : ok
  8-bit Writes : ok
  16-bit Writes : ok

Done.

[HH King (havelock)]

If this only happens when viewpoint.y = 0 then I should have been using a tiny map to trigger it, not big ones.

[GunChleoc (gunchleoc)]

So, a buffer overflow in the zoom when viewpoint y is 0.0. This gives me a good starting point to do some digging :)

I do not think that you need to continue looking into the memory usage. I have started to work on some optimizations for Build 21, but there is no obvious memory leak. We get some small leaks from the Lua backend, but they are just a few KB and shouldn't max out the memory, so that was pretty strange.

Our biggest memory spike is from the Lua tables when starting a new game, and we get another memory increase when saveloading. Zooming out a lot also needs lots of memory for the animations. That should be alleviated somewhat when we implement mipmaps (already work in progress).

[GunChleoc (gunchleoc)]

I have dug into the zoom code and I don't understand yet why it can become negative. I have added more logging output to the branch.

[kaputtnik (franku)]

- Seems it happens only in a very rare corner case.
- There are no clear steps to reproduce this.

If you think it is worth apply your hotfix mentioned in #26 and please postpone this to build21 again.

[GunChleoc (gunchleoc)]

I think since we have negative zoom in other places as well, the hotfix idea won't be sufficient - it will just crash somewhere else. So, I'd rather wait until the weekend before doing anything hasty that we will regret later.

[kaputtnik (franku)]

I understand your willing to fix this... sorry if my words sounds too harsh. Anyway i think a release can't be free of bugs, like any program.

I just fear to frustrate all people: the developers who want to implement new features and the gamers who want to get the benefits from the new release. If there is a bug, which, in this case, happens very rarely, i can live with that. Having a new release is currently much more important than fixing this bug, imho.

I have tried to reproduce this bug with the attached save game and the fieldstodraw_assert branch, trying to get the viewpoint to the last positions where it crashes, no luck (no crash).

HHKing: Are you playing in Fullscreen mode? Did you switched to/from Fullscreen mode? Which Resolution have you set in the game options? Do you used viewpoint markers (STRG+number)? Can you remember what you have done close before the crash happens?

[HH King (havelock)]

I admit I'm starting to feel a bit guilty about this bug :) Being 8 or 9 timezones west of europe doesn't help with responses either. Most games are going to be a lot shorter than it seems to take to trigger such a rare bug. If I wasn't new to the game and figuring things out and looking at the graphics, etc, I doubt I would have played games long enough or done enough zooming to see it.

The last assert was not fullscreen - set at 1280x720. I have used fullscreen but did not trigger the bug. I was not using any viewpoint markers. I can't think of anything I was doing that is in common when the bug happens. Last time I had memory in mind and was just letting the game run and playing 10 minutes here and there to keep things going. I think I left it zoomed out for some time, came back to the game and moved the view around a bit then hit the zoom reset.

I use the mousewheel to zoom, not the keyboard.

I've been trying using the logging to move the viewpoint to the same location but can't quite get to the exact coordinates (rounding?). Working backward from viewpoint (6144.00, 0.00) and zooming out does not take me anywhere near viewpoint (14042.43, 2334.09) either.

[HH King (havelock)]

I didn't switch to/from fullscreen during any run where it crashed.

[kaputtnik (franku)]

You don't have to feel guilty, you should feel proud because you have found this bug :-)

We are close to a new official release, and GunChleoc and i have different meanings if this bug should be fixed for the official release or not. But this doesn't mean the bug will never be fixed.

[hessenfarmer (stephan-lutz)]

I fully agree to kaputtnik.

this bugreport already led to a couple of valuable fixes and improvements. So better be proud than feel guilty

[GunChleoc (gunchleoc)]

Exactly - thank you very much for reporting and continuing to test. You are not part of the problem, but of the solution! You did not cause the bug, you just discovered it and have already helped us make some very valuable fixes.

[GunChleoc (gunchleoc)]

I think we should call winter freeze next weekend, whether this bug is fixed or not. We can always mention it as a known issue if we can't fix it. I'd rather not add any ad hoc workarounds at this point.

@HH King: Could you keep playing with the branch that creates the log output? It will be compatible with the new release in case you want to play multiplayer.

[HH King (havelock)]

This is Widelands Version bzr9027[bug-1818494-fieldstodraw-assert] (Debug)
...
**************************
NOCOM viewpoint (7774.51, 2020.95), zoom: 4.00
NOCOM dst (0, 0, 1280, 720)
NOCOM br_map (12894.51, 4900.95)
NOCOM min_f (121, 63), max_f (202, 154)
NOCOM adjusted min_f (119, 61), max_f (204, 164)
NOCOM w, h (86, 104)
NOCOM draw_terrain (7774.51, 2020.95) @ 4.00
**************************
NOCOM viewpoint (7774.51, 2020.95), zoom: 4.00
NOCOM dst (0, 0, 1280, 720)
NOCOM br_map (12894.51, 4900.95)
NOCOM min_f (121, 63), max_f (202, 154)
NOCOM adjusted min_f (119, 61), max_f (204, 164)
NOCOM w, h (86, 104)
NOCOM plan zoom transition from 4.00 to 1.00
NOCOM add planned zoom: 4.00
NOCOM add planned zoom: 4.00
NOCOM add planned zoom: 4.00
NOCOM add planned zoom: 3.99
NOCOM add planned zoom: 3.99
NOCOM add planned zoom: 3.98
NOCOM add planned zoom: 3.97
NOCOM add planned zoom: 3.96
NOCOM add planned zoom: 3.95
NOCOM add planned zoom: 3.93
NOCOM add planned zoom: 3.92
NOCOM add planned zoom: 3.90
NOCOM add planned zoom: 3.89
NOCOM add planned zoom: 3.87
NOCOM add planned zoom: 3.85
NOCOM add planned zoom: 3.82
NOCOM add planned zoom: 3.80
NOCOM add planned zoom: 3.78
NOCOM add planned zoom: 3.75
NOCOM add planned zoom: 3.73
NOCOM add planned zoom: 3.70
NOCOM add planned zoom: 3.67
NOCOM add planned zoom: 3.64
NOCOM add planned zoom: 3.61
NOCOM add planned zoom: 3.58
NOCOM add planned zoom: 3.55
NOCOM add planned zoom: 3.51
NOCOM add planned zoom: 3.48
NOCOM add planned zoom: 3.45
NOCOM add planned zoom: 3.41
NOCOM add planned zoom: 3.37
NOCOM add planned zoom: 3.34
NOCOM add planned zoom: 3.30
NOCOM add planned zoom: 3.26
NOCOM add planned zoom: 3.22
NOCOM add planned zoom: 3.18
NOCOM add planned zoom: 3.14
NOCOM add planned zoom: 3.10
NOCOM add planned zoom: 3.06
NOCOM add planned zoom: 3.02
NOCOM add planned zoom: 2.98
NOCOM add planned zoom: 2.94
NOCOM add planned zoom: 2.89
NOCOM add planned zoom: 2.85
NOCOM add planned zoom: 2.81
NOCOM add planned zoom: 2.76
NOCOM add planned zoom: 2.72
NOCOM add planned zoom: 2.68
NOCOM add planned zoom: 2.63
NOCOM add planned zoom: 2.59
NOCOM add planned zoom: 2.54
NOCOM add planned zoom: 2.50
NOCOM add planned zoom: 2.46
NOCOM add planned zoom: 2.41
NOCOM add planned zoom: 2.37
NOCOM add planned zoom: 2.32
NOCOM add planned zoom: 2.28
NOCOM add planned zoom: 2.24
NOCOM add planned zoom: 2.19
NOCOM add planned zoom: 2.15
NOCOM add planned zoom: 2.11
NOCOM add planned zoom: 2.06
NOCOM add planned zoom: 2.02
NOCOM add planned zoom: 1.98
NOCOM add planned zoom: 1.94
NOCOM add planned zoom: 1.90
NOCOM add planned zoom: 1.86
NOCOM add planned zoom: 1.82
NOCOM add planned zoom: 1.78
NOCOM add planned zoom: 1.74
NOCOM add planned zoom: 1.70
NOCOM add planned zoom: 1.66
NOCOM add planned zoom: 1.63
NOCOM add planned zoom: 1.59
NOCOM add planned zoom: 1.55
NOCOM add planned zoom: 1.52
NOCOM add planned zoom: 1.49
NOCOM add planned zoom: 1.45
NOCOM add planned zoom: 1.42
NOCOM add planned zoom: 1.39
NOCOM add planned zoom: 1.36
NOCOM add planned zoom: 1.33
NOCOM add planned zoom: 1.30
NOCOM add planned zoom: 1.27
NOCOM add planned zoom: 1.25
NOCOM add planned zoom: 1.22
NOCOM add planned zoom: 1.20
...

[GunChleoc (gunchleoc)]

Thanks a lot, that helps! I have added a fix to the logging branch - would you have more time to test if you can still trigger the bug with that?

[HH King (havelock)]

This is Widelands Version bzr9028[bug-1818494-fieldstodraw-assert] (Debug)
...
**************************
NOCOM viewpoint (8798.04, 2857.95), zoom: 2.54
NOCOM dst (0, 0, 1280, 720)
NOCOM br_map (12044.56, 4684.12)
NOCOM min_f (137, 89), max_f (189, 147)
NOCOM adjusted min_f (135, 87), max_f (191, 157)
NOCOM w, h (57, 71)
NOCOM draw_terrain (8798.04, 2857.95) @ 2.54
**************************
NOCOM viewpoint (8798.04, 2857.95), zoom: 2.54
NOCOM dst (0, 0, 1280, 720)
NOCOM br_map (12044.56, 4684.12)
NOCOM min_f (137, 89), max_f (189, 147)
NOCOM adjusted min_f (135, 87), max_f (191, 157)
NOCOM w, h (57, 71)
NOCOM plan zoom transition from 2.54 to 1.00
NOCOM add planned zoom: 2.54
NOCOM add planned zoom: 2.54
NOCOM add planned zoom: 2.53
NOCOM add planned zoom: 2.53
NOCOM add planned zoom: 2.53
NOCOM add planned zoom: 2.53
NOCOM add planned zoom: 2.52
NOCOM add planned zoom: 2.52
NOCOM add planned zoom: 2.51
NOCOM add planned zoom: 2.50
NOCOM add planned zoom: 2.49
NOCOM add planned zoom: 2.49
NOCOM add planned zoom: 2.48
NOCOM add planned zoom: 2.47
NOCOM add planned zoom: 2.46
NOCOM add planned zoom: 2.45
NOCOM add planned zoom: 2.43
NOCOM add planned zoom: 2.42
NOCOM add planned zoom: 2.41
NOCOM add planned zoom: 2.40
NOCOM add planned zoom: 2.38
NOCOM add planned zoom: 2.37
NOCOM add planned zoom: 2.35
NOCOM add planned zoom: 2.34
NOCOM add planned zoom: 2.32
NOCOM add planned zoom: 2.30
NOCOM add planned zoom: 2.29
NOCOM add planned zoom: 2.27
NOCOM add planned zoom: 2.25
NOCOM add planned zoom: 2.23
NOCOM add planned zoom: 2.22
NOCOM add planned zoom: 2.20
NOCOM add planned zoom: 2.18
NOCOM add planned zoom: 2.16
NOCOM add planned zoom: 2.14
NOCOM add planned zoom: 2.12
NOCOM add planned zoom: 2.10
NOCOM add planned zoom: 2.08
NOCOM add planned zoom: 2.06
NOCOM add planned zoom: 2.03
NOCOM add planned zoom: 2.01
NOCOM add planned zoom: 1.99
NOCOM add planned zoom: 1.97
NOCOM add planned zoom: 1.95
NOCOM add planned zoom: 1.93
NOCOM add planned zoom: 1.90
NOCOM add planned zoom: 1.88
NOCOM add planned zoom: 1.86
NOCOM add planned zoom: 1.84
NOCOM add planned zoom: 1.81
NOCOM add planned zoom: 1.79
NOCOM add planned zoom: 1.77
NOCOM add planned zoom: 1.75
NOCOM add planned zoom: 1.72
NOCOM add planned zoom: 1.70
NOCOM add planned zoom: 1.68
NOCOM add planned zoom: 1.66
NOCOM add planned zoom: 1.63
NOCOM add planned zoom: 1.61
NOCOM add planned zoom: 1.59
NOCOM add planned zoom: 1.57
NOCOM add planned zoom: 1.55
NOCOM add planned zoom: 1.52
NOCOM add planned zoom: 1.50
NOCOM add planned zoom: 1.48
NOCOM add planned zoom: 1.46
NOCOM add planned zoom: 1.44
NOCOM add planned zoom: 1.42
NOCOM add planned zoom: 1.40
NOCOM add planned zoom: 1.38
NOCOM add planned zoom: 1.36
NOCOM add planned zoom: 1.34
NOCOM add planned zoom: 1.32
NOCOM add planned zoom: 1.30
NOCOM add planned zoom: 1.28
NOCOM add planned zoom: 1.27
NOCOM add planned zoom: 1.25
NOCOM add planned zoom: 1.23
NOCOM add planned zoom: 1.22
NOCOM add planned zoom: 1.20
NOCOM add planned zoom: 1.18
NOCOM add planned zoom: 1.17
NOCOM add planned zoom: 1.15
NOCOM add planned zoom: 1.14
NOCOM add planned zoom: 1.13
NOCOM add planned zoom: 1.11
NOCOM add planned zoom: 1.10
NO...

[GunChleoc (gunchleoc)]

Thanks! I have added another attempted fix to the branch.

[hessenfarmer (stephan-lutz)]

Anything new on this one?

@ HH King maybe you could give an indication whether you have tested the latest attempt of Gun Chleoc and what were the results

[HH King (havelock)]

I can not make it crash any more :) I am returning to using the main branch now.

[GunChleoc (gunchleoc)]

Excellent! I'll put up a merge request so that we can get the fix in for Build 20.

[GunChleoc (gunchleoc)]

Fixed in build20-rc1