bzr7684[trunk] Crash on upcast in defaultai.cc:5381

[Klaus Halfmann]

I compiled a trunk and a slightly modified Version on OSX 10.11.2 (15C50) with MacPorts and XCode Version 7.2 (7C68)

   5378 uint32_t site_to_be_removed = std::numeric_limits<uint32_t>::max();
   5379 Flag* flag = nullptr;
   5380
   5381 if (upcast(MilitarySite, bld, f.field->get_immovable())) {
   5382 if (player_->is_hostile(bld->owner())) {
   5383 std::vector<Soldier *> defenders;

I played a self defined map (Schrägland) Barbarians vs. Empire,
after attacking the Empire at a small Bulding - to avoid the castle being built -
THe Empire attacked be back. So I teaead down my barrack. But before my soldiers
could leave the game caresd with a secfault:

After testing I found:
* I could not reproduc this on a plain "r7684" compiled by SirVer.
* I _could_ reproduc this in some debug version bzr7684[trunk]
* In the version I modified bzr7684[feature-Hasi50]

The behaviour was different when I reloaded the saved File, so I assume it
is either base on som unititalized memory or some racecondition
(This is a MacBook with 2,3 GHz Intel Core i7, 8 crores via MultiThreading)

I may Attach more Info if possible and/or requested

[TiborB (tiborb95)]

I compiled trunk (rev. 7686) and attacked the sentry at 11x39 (correct one?) - no crash...

This part of AI code is quite old, should be OK.

>The behaviour was different when I reloaded the saved File

Most of AI data are not stored in savegame. So when you load the game, AI has to recreate them gradually. So in fact you never get the same status after save/load.

Linux has GDB debugger, I think it could provide much better backtrace then the one provided.

[Klaus Halfmann (klaus-halfmann)]

I manage to repdroduce with an XCode Debugger Attached to bzr7689[trunk]

The crash happend here in player.h

        // See area
 Vision vision(MapIndex const i) const {
  // Node visible if > 1
  return (m_see_all ? 2 : 0) + m_fields[i].vision;
 }

where i is Widelands::MapIndex 2091776 2091776

called from here:

  // we cannot attack unvisible site and there is no other way to find out
  const bool is_visible = (1 < player_->vision
     (Map::get_index(coords_unhash(site->first), map.get_width())));

Please conact me so we may set up a skype teamviewer or whatever session,
I am pretty sure I can reproduce this now.

[TiborB (tiborb95)]

@Klaus
Please test if possible lp:~widelands-dev/widelands/bug-1530999 - I modified the function check_enemy_sites, hopefully this is the same problem...

[GunChleoc (gunchleoc)]

Maybe m_fields[i] = nullptr, that would cause a crash.

[Klaus Halfmann (klaus-halfmann)]

Hello Tibor I compiled lp:~widelands-dev/widelands/bug-1530999 and tried it three times.
The third time the AI behaved in the same way as when I found that crash.
I suppose we wait until this was mergen into trunk, then I will try again
with trunk or my current branch, and then we can close this.

@GnuChleoc: @m_fields[i] was not null but i was much to hig 2.091.776) which
I am sure is unhealthy :-) But give me some more time to dig into that Map

[TiborB (tiborb95)]

Hi

>I compiled lp:~widelands-dev/widelands/bug-1530999 and tried it three times.
> The third time the AI behaved in the same way as when I found that crash.

Not good :(

>I suppose we wait until this was mergen into trunk

Should make no difference (if you properly tested my branch), but test it, of course. BTW, it was already merged.

> (Map::get_index(coords_unhash(site->first), map.get_width())));

I believe problem must be in site->first that contains nonsensical number, perhaps invalid iterator??? But invalid iterator was a bug I fixed in my bug-1530999 branch. So let me know how your test went...

[TiborB (tiborb95)]

I created a branch, but I added there only asserts to verify that militarysites coordinates are within map size.

@Klaus Please check a backtrace from a crash, just be sure there is the same problem as you mentioned in post https://bugs.launchpad.net/widelands/+bug/1530560/comments/4 .

[SirVer (sirver)]

I ran the game for an hour at high speed with many computers and I could not repro this problem again.

[TiborB (tiborb95)]

$ time ./wl_make_texture_atlas 8192
Graphics: Try to set Videomode 1x1
Graphics: OpenGL: Version "3.0 Mesa 11.0.7"
Graphics: OpenGL: Double buffering enabled
Graphics: OpenGL: Max texture size: 8192
**** GRAPHICS REPORT ****
 VIDEO DRIVER x11
 pixel fmt 370546692
 size 640 480
**** END GRAPHICS REPORT ****
libpng warning: iCCP: known incorrect sRGB profile #REPEATED couple of times

real 1m14.118s
user 0m41.267s
sys 0m5.100s

$ ls -al output*
-rw-r--r-- 1 tibor tibor 33135351 jan 7 21:54 output_00.png
-rw-r--r-- 1 tibor tibor 34348444 jan 7 21:54 output_01.png
-rw-r--r-- 1 tibor tibor 4961263 jan 7 21:54 output.lua

$ time ./wl_make_texture_atlas 16384
........
real 0m33.660s
user 0m32.740s
sys 0m0.730s

ls -al output*
-rw-r--r-- 1 tibor tibor 440653 jan 7 21:58 output_00.png
-rw-r--r-- 1 tibor tibor 4983963 jan 7 21:58 output.lua
[p0kus@SuperFort3 ~]$

[TiborB (tiborb95)]

ooops, ignore the post above - is was wrong tab in browser :(

[Klaus Halfmann (klaus-halfmann)]

Was playing this yesterday with bzr7689[trunk] tried the secen again 3 times
and then played the game further, but dind not find any crash -> OK for me

[GunChleoc (gunchleoc)]

Fixed in build19-rc1.