segfault on dismantle on conquered enemy building or starting buildings in campaigns

[willem]

Build bzr 6667, self compiled on linux

Dismantling a conquered enemy building (same tribe) results in a segmentation fault. Also the returns popup shows no materials to return.

Same issue can also be triggered by attempting to dismantle any of the "starting buildings" in campaign maps, presumably because these are considered "conquered". See comments below and duplicate bug 1205437 for details.

[Hans Joachim Desserud (hjd)]

Hi willem and welcome to Launchpad.

Thanks for reporting this issue. I just played a game now with r6667 and it does indeed crash when I try to dismantle an enemy building even though I'm playing the same tribe.

We've had a similar problem before, just after dismantling was introduced. It would crash when dismantling buildings from other tribes, but I believe buildings for your own tribe worked at the time (see bug 886808 for details).

[SirVer (sirver)]

Charly, I guess (without really checking) that this was introduced with your prior building stack patch. Could you have a look and also try dismantling buildings from other tribes as well?

[cghislai (charlyghislain)]

Probably, I will look into that

[MP (pagel-d)]

clarification for 1205437: 1205437 is re: (non-military) buildings under player's control (not enemy) at start of mission.

120510 only mentions enemy-constructed military buildings, presumably not part of the AI's starting complement of buildings, but rather constructed during the course of the game.

In other words, the scope of 120510 is greater than the initial report.

[cghislai (charlyghislain)]

I tested this in the linked branch (barbarian 2) and i experienced no crash.
The fix works on the force_building function, with also a fix when called from lua.

[MP (pagel-d)]

I won't get a chance to check this bug fix or my other report until Monday or Wednesday of next week. Don't wait for me to release:P

[Hans Joachim Desserud (hjd)]

MP: I don't know how this works, but my guess is that since the player didn't build the starting buildings, they count as "conquered" which triggers the same crash. I tried with the attached branch, I am no longer able to trigger a crash when dismantling the starting buildings in barbarian map 2. Therefore I believe both this and bug 1205437 are caused by the same underlying issue. I've updated the title to reflect this now.

PS. If you write the word "bug" in front of the bug numbers, Launchpad will automatically create a link. :)

[willem (wiz-e)]

Hi, iv'e tried rev 6668. dismantling of conquered buildings now works, also buildings created by a campaign can be dismantled. But iv'e discovered a new related problem, when starting with a village instead of a headquarters dismantling of some of the created buildings still results in a crash. That is traningscamp was ok but castle and colosseum cause a crash.

[willem (wiz-e)]

looks like prebuild buildings which are normally build in 2 stages stiil cant be dismantled. So Atlantean castle is ok but empire castle isn't and also babarian axe factory

[cghislai (charlyghislain)]

ok thanks for that, i see were the issue might lie.

[cghislai (charlyghislain)]

this is fixed in the branch now

[MP (pagel-d)]

using a savegame generated by 6667, this bug still crashes 6680.

As Barbarian, one of my sentries (that I built) was taken over by the Atlanteans, which I subsequently re-captured (in 6667). Dismantle in both 6667 and 6680 crashes the game.

Same with a sentry that I ordered the attack of in 6667, but actually won the combat using 6680. Of course this sentry had changed hands a couple of times in 6667.

[MP (pagel-d)]

in fact, a building that was never attacked or conquered by the enemy in 6667, if lost and recaptured in 6680, it cannot be dismantled. It can be dismantled before the enemy attacks it.

So, I don't believe this is fixed in the main branch yet.

Again, destruction of the building does not crash the game, only dismantle.

[cghislai (charlyghislain)]

Thanks for the savegame. It crashes as soon as it is captured here.
Please note that the fix I spoke about is in the linked branch 'bug1205010', not yet in trunk.

[cghislai (charlyghislain)]

Ok, I see the issue here. The changes introduced by r6656 included a bug (this one), which is that information about the former buildings is not transfered to the new owner upon militarysite conqueral. So savegames produced with later revisions will contain the bug. The fix is in the linked branch (https://code.launchpad.net/~widelands-dev/widelands/bug1205010), but as of typing it will load silently such buggy savegames, leading to a crash while playing afterwards.
So I don't know if I should deal with such case. I guess I should trust the savegame. I may still add an assert to prevent loading of such buggy savegames, but I fear your savegame won't be playable.

[MP (pagel-d)]

Just a comment...not requesting further action:

fyi Build 6691 (which if I'm understanding the notation correctly has been merged into trunk), likely addresses this issue correctly with new games (further testing pending).

However, the save game liked to dup bug 1205944 (m2f) loads just fine initially, but buildings previously captured from my first opponent were non-dismantle-able. Additionally, as my 5th or so attack against green was concluding the game crashed. I'm assuming this was just the time it took for one of the AIs to attempt a dismantle of a captured structure as before.

The game I linked to this bug report (sc1) appears to load for about a 1/4 second, but promptly crashes out (while a battle is occurring, but before its conclusion)

You did say "but I fear your savegame won't be playable" - which is correct. Just thought it should be noted that the assert-on-load (if added) didn't catch this.

[cghislai (charlyghislain)]

While trying to load your savegame, (m2f) the game crash at that line during loading:
assert(!building.m_old_buildings.empty() || is_a(ConstructionSite, &building));

Maybe you have built the game in release mode, in which case I think all asserts are removed.

[MP (pagel-d)]

possibly not fixed, although this was not specific to conquered or starting buildings

Most recent attachment to Bug #1203329, I got a crash once (but not on repeat) for clicking on dismantle for the lower-left barracks (near the forester hut there)

[MP (pagel-d)]

I'm using the daily builds for win32.

[Hans Joachim Desserud (hjd)]

Earlier today I ran into a random crash when watching three AI players (single player game with me as the fourth, though I didn't build anything). Unfortunately, I was for once playing the game outside gdb, so I don't have a stacktrace. When watching the replay I didn't get a crash, but the message "REPLAY: Caught exception Stream ended unexpectedly (0 bytes read, 1 expected)" like in duplicate bug 1206197.

This was with latest trunk (6695).

[Hans Joachim Desserud (hjd)]

On second thought, my issue in comment #22 was likely bug 1208229.

[cghislai (charlyghislain)]

In reply to #20: That savegame is buggy, see comment #10 in that bug and comment #17 here.
Please remove those savegames as you will run into issues with them, or build widelands in debug mode so you will run into the assert on loading.
Maybe I should rather throw an exception in place of the assert.

[SirVer (sirver)]

+1 for exception.

[dershrimp (dershrimp)]

Playing widelands with ubuntu 12.04 LTS, since some revisions ago I have this kind of bug, but more generally.
Actually I was now playing r6729. Dismantling of any type of building cause the game to crash. There is no preview of the ressources neither. Additionally the game crashes "randomly" presumably when the computerplayers try to dismantle a building.
I tried this with different maps and winconditions. Always the same.

[dershrimp (dershrimp)]

I opened a new bug report as the bug is actually a bit different: bug #1220546

[Hans Joachim Desserud (hjd)]

dershrimp: Thanks for filing a new bug report. Since that seems unrelated I'll revert the status of this.

[SirVer (sirver)]

Released in build-18 rc1.