segfault on dismantle window in empire Mission4

#1 Looks like one of the scenario's custom buildings doesn't have a representative image defined. We should add a check for that.

I have to say that the assert with representative_image happens only one time during starting the game for about 15 times.

This morning i couldn't trigger any of the segfaults :-S

*lol* as soon i wrote i couldn't trigger the segfault this morning, it happens again...

I think i know how to trigger it: The wells in the east shouldn't produce water. But sometimes they are producing water. Dismantling then causes the crash. I am in hurry for now so my assumption has to be verified.

It's not the well.

It happens when the last buildings wants to be dismantled.

Also strange: Sometimes a window pops which should only pop up when clicking on a farm.

Ok will have a look on that this evening.
The issue with the unwanted window should have been solved. Anyhow I will try to fix this again.

@ GunChleoc: The issue with the unwanted Pop of the window would be easier if I could directly check for the Name of the building.

The mechanism why it is triggering is that I check if a building window is opened and if it has not a dismantle button and if it has no wares tab. So if you close any building window right after the first condition has been confirmed then the negative tests are automatically true. will need to implement a safecheck to prevent this.

The dynamic_tribe_loading branch has a bug in it that there are nonexistent wares during cleanup. I have found the commit that causes the bug, but I don't understand why it's happening yet.

If you run

    bzr revert -r8438

on that branch and recompile, that might fix the crash.

@ Gun Chleoc :
maybe I brought in some confusion with my comment. As far as I understand the original bug (segfault when dismantling) was found in trunk and therefore ther is no dependency to the "dynamic tribe loading" branch. I will test although I have not seen this yet.

The other thing is the unwanted popup of the messages window delivering the farm plans objective. This I have seen before and built in a second check if the right window is still open. However this seems not to work therefore I will have a look and try to prevent this. The solution just would be easier if I could check for a specific Building window as already discussed in the Mission 4 forum thread.

Still we will need to look for the reason why the bug is happening in trunk 8440. May suggest that kaputtnik will try a newer revision and check if it is still there. Another important information would be which OS he is using. I am on win 10 build 1607 and didn't saw the behaviour in my test installation which is r8478

ok
the message after dismantling the buildings was triggered without any delay maybe this could have caused some problems. I inserted a sleep(2000) before so now the mesage is discoupled from the last dismantling. Don't know whether this was the problem though cause I couldn't reproduce the segfault. Maybe the diversion between datadir (nearly actual revision) and trunk revision of kapputnik (8440) could have a negative impact too.
Regarding the unwanted window I found another condition to check for which should prevent the problem. I couldn't trigger the message again which I could in the revision before.
new revision is up please kaputtnik check again

I need to know more about #8 - please open a new bug and tell me if you need the building type (e.g. "empire_farm") or the building's serial number.

in this case the name would be sufficient, but if it is not to much work other attributes of the building window could be helpful as well I'll create a new bug with all attributes I consider possibly valuable for scenario design

Hm, starting the game from the Mission4 branch and starting from trunk with option --datadir shows different results:

Mission4 branch r8436 last updated with trunk on 2017-11-10 :
1. Shows a lot of " 2: Players statistics are still empty" lines in the console. I remember there was a bug regarding this which was solved?
2. The game crashes reproducible while saving after solving the first objective with a segfault:

> Thread 1 "widelands" received signal SIGSEGV, Segmentation fault.
> 0x00007ffff5148506 in __strlen_sse2 () from /usr/lib/libc.so.6

Starting from trunk r8487:
All works fine, also the lines with missing Player statistics aren't shown.

I am on linux.

As I am on windows I just have the possibilty to use datadir option currently. I could launch a merge request which would trigger an appveyor build though to check it. But I don't know how to interpret the attached textfile. I can't imagine why a branch with merged trunk could behave different then trunk itself. Please tell me what to do.
Did you see the original crashes in the latest revision though. was the fix of adding some sleeptime sufficient. still I don't understand why a this could have caused a crash.

Maybe i messed up some things... i will try to compile the Mission4 branch from scratch and test again.

A crash similar to #12 was fixed recently: https://bugs.launchpad.net/widelands/+bug/1724073

Seems like there is more to it.

Ok, after downloading a fresh copy and compiling it seems to work now. But i want to make some more tests... maybe after my tournament game this evening.

Ok I will do nothing until kaputtnik has checked the issue again.

Good luck in the tournament then.

Lost the tournament game :-)

The crash mentioned in this bug is imho gone. But i get very rarely the crash of representative_image (for about 1 time when starting the campaign 15 times):

building_window: table: 0x555562270180
Buttons disamntle: nil
Tab wares: nil

Thread 1 "widelands" received signal SIGSEGV, Segmentation fault.
0x000055555629f56f in BuildingWindow::draw (this=0x5555623efdb0, dst=...) at ../src/wui/buildingwindow.cc:134
134 const Image* image = building().representative_image();

Couldn't reproduce with specific steps. Maybe this is related with bug 1691336 (Building window changes its assigned window)?

GunChleoc should decide if this bug is fixed for now, i would mark it as fixed.

Fixed in build20-rc1