bugBattle for Wesnoth - Bugs: bug #13256, Assertion failure in ...

Show feedback again

bug #13256: Assertion failure in src/actions.cpp, happened when moved (12,8)-> (10,10)

Submitted by:  Iurii Chernyi <crab>
Submitted on:  Tue Mar 24 20:44:51 2009  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Units
Status: FixedPrivacy: Public
Assigned to: J Tyne <jamit>Open/Closed: Closed
Release: 33853:34011MOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


(Jump to the original submission Jump to the original submission)

Sun Jan 10 17:06:37 2016, comment #11:

marking as fixes becasue

> The assertion failure is fixed

this was before 1.12

Daniel <gfgtdf>
Project Member
Mon Jul 13 18:32:55 2015, comment #10:

There are a lot of ways to abuse [allow_undo] and i see no reason why we should specially guard against [kill] or [(un)store_unit] (specially since it doesn't cause crashs anymore).

Also i think there could be cases where a wml developer want to use [kill] or simiar inside a undoable event which does not casue bugs/OOS, for example one might want to create a temporary unit to calculate its attack stats (to show it in a message) and then remove the unit after it.

Daniel <gfgtdf>
Project Member
Sun Dec 15 03:43:25 2013, comment #9:

The assertion failure is fixed, but the underlying problem of not clearing the undo stack when [kill] is used remains.

I'm going to re-open this to remind me to get back to this after 1.12 is released. (I also lowered the severity since it is no longer a hard crash.)

J Tyne <jamit>
Project MemberIn charge of this item.
Tue Dec 3 18:29:54 2013, comment #8:

I can no longer reproduce this issue, unit_map has since been changed so its iterators never invalidate, the files that are referred to have both been split up and the fragments themselves have changed quite a bit.

I'm marking this as fixed and closed, as it has probably ceased to be an issue since before 1.10.0.

Alexander van Gessel <ai0867>
Project Member
Tue Nov 17 21:19:47 2009, comment #7:

postponing resolution of this bug to 1.9, since there's a quite a number of issues which should be solved to properly fix that bug.

Iurii Chernyi <crab>
Project Member
Fri May 1 19:26:27 2009, comment #6:

Please make your patch generic, since it will also have to be applied to the [unit], [store_unit], and [unstore_unit] events.

Guillaume Melquiond <silene>
Thu Mar 26 21:20:26 2009, comment #5:

according to zookeeper, correct behavior should be:

"killing a unit should unvalidate all undo moves, including those
which are not related to this unit"

so, BEFORE 'units->erase(un);', shroud changes are to be applied, and undo moves are to be invalidated.

I will try to make up a patch to do that.

Iurii Chernyi <crab>
Project Member
Tue Mar 24 23:57:57 2009, comment #4:

The problematic code fragments are:

event_mutated |= game_events::pump();
ui = units.find(steps.back());

if(undo_stack != NULL) {
if(event_mutated || should_clear_stack || ui == units.end())
} else {

and see src/game_events.cpp:2156
if (fire_event)
game_events::fire("die", death_loc, death_loc);
un = units->find(death_loc);
if(un != units->end() && death_loc.matches_unit(un->second)){

Because of the previous movement, undo_stack includes a 'undo' item with a unit FOO. There is a WML event to kill a unit that steps on a specified hex. Combination of those factors leads to assertion failure. Here's how:

1. the unit steps on that hex.

2. game_events::pump() pumps a WML event to kill unit FOO. (see src/game_events.cpp:2156 ). so, FOO is removed from 'units'.

3. as ui == units.end(), apply_shroud_changes(.....) is called.

4. apply_shroud_changes tries to do 'run through the list of undo_actions, for each location along the route, clear any "shrouded" hexes that the unit can see and record sighted events'

5. apply_shroud_changes finds the shroud action with the unit FOO. It tries to find unit FOO in the list of units. of course, it fails, as FOO was already deleted.

6. assert(unit_itor != units.end()); fails - assertion failure.

Iurii Chernyi <crab>
Project Member
Tue Mar 24 21:56:46 2009, comment #3:

start test scenario
move (12,8)->(12,9)
move (12,9)->(12,8) [so undo action with it becomes available]
move (12,8)->(10,10)

so, the bug happens because unit, who is referenced in the undo list, moves and is deleted by WML, and the movement triggers shroud update which asserts(that the unit is still around)

Iurii Chernyi <crab>
Project Member
Tue Mar 24 21:28:12 2009, comment #2:

an example backtrace (the bug triggers not every time, but it is possible to reproduce by moving a unit and move it to (10,10). then it is killed by WML event, and then the bug may trigger

Program received signal SIGABRT, Aborted.
0xb7f85424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f85424 in __kernel_vsyscall ()
#1 0xb786e640 in raise () from /lib/i686/cmov/libc.so.6
#2 0xb7870018 in abort () from /lib/i686/cmov/libc.so.6
#3 0xb78675be in __assert_fail () from /lib/i686/cmov/libc.so.6
#4 0x08463a6f in apply_shroud_changes (undos=@0xbfa9e0bc, disp=0xb6bfd20,
map=@0xbfa9dfac, units=@0xbfa9e084, teams=@0xbfa9df70, team=0)
at src/actions.cpp:2588
#5 0x0846af2d in move_unit (disp=0xb6bfd20, map=@0xbfa9dfac,
units=@0xbfa9e084, teams=@0xbfa9df70, route=
{<std::_Vector_base<map_location, std::allocator<map_location> >> = {_M_impl = {<std::allocator<map_location>> = {<__gnu_cxx::new_allocator<map_location>> = {<No data fields>}, <No data fields>}, _M_start = 0xbfa9cfc8, _M_finish = 0x8979920, _M_end_of_storage = 0xbfa9e0bc}}, <No data fields>},
move_recorder=0x8979920, undo_stack=0xbfa9e0bc, next_unit=0xbfa9deac,
continue_move=false, should_clear_shroud=true, is_replay=false)
at src/actions.cpp:2419
#6 0x085623a0 in events::mouse_handler::move_unit_along_current_route (
this=0xbfa9de50, check_shroud=true, attackmove=false)
at src/mouse_events.cpp:506
#7 0x08564703 in events::mouse_handler::left_click (this=0xbfa9de50, x=334,
y=444, browse=false) at src/mouse_events.cpp:420
#8 0x081b1330 in events::mouse_handler_base::mouse_press (this=0xbfa9de50,
event=@0xa1796c0, browse=false) at src/mouse_handler_base.cpp:134
---Type <return> to continue, or q <return> to quit---
#9 0x08561776 in events::mouse_handler::mouse_press (this=0xbfa9de50,
event=@0xa1796c0, browse=false) at src/mouse_events.cpp:332
#10 0x084ca1f5 in controller_base::handle_event (this=0xbfa9de10,
event=@0xa1796c0) at src/controller_base.cpp:79
#11 0x086cf765 in events::pump () at src/events.cpp:382
#12 0x084c9e4b in controller_base::play_slice (this=0xbfa9de10)
at src/controller_base.cpp:185
#13 0x082125dc in playsingle_controller::play_human_turn (this=0xbfa9de10)
at src/playsingle_controller.cpp:710
#14 0x082128dd in playsingle_controller::play_side (this=0xbfa9de10,
team_index=1, save=false) at src/playsingle_controller.cpp:611
#15 0x08213497 in playsingle_controller::play_turn (this=0xbfa9de10,
save=false) at src/playsingle_controller.cpp:565
#16 0x082159eb in playsingle_controller::play_scenario (this=0xbfa9de10,
story=@0xbfa9e69c, log=@0xbfa9ef24, skip_replay=false,
end_level_result=0xab3f7b0) at src/playsingle_controller.cpp:316
#17 0x08202954 in playsingle_scenario (game_config=@0xbfa9f078,
level=0xbfa9f1cc, disp=@0xa1871a0, state_of_game=@0xbfa9f0d4,
story=@0xbfa9e69c, log=@0xbfa9ef24, skip_replay=false, end_level=0xab3f7b0)
at src/playcampaign.cpp:132
#18 0x08206c34 in play_game (disp=@0xa1871a0, gamestate=@0xbfa9f0d4,
game_config=@0xbfa9f078, log=@0xbfa9ef24, io_type=IO_NONE,
skip_replay=false) at src/playcampaign.cpp:367
---Type <return> to continue, or q <return> to quit---
#19 0x0805cdd7 in launch_game (this=0xbfa9f02c,
reload=(anonymous namespace)::game_controller::NO_RELOAD_DATA)
at src/game.cpp:1635
#20 0x0806b244 in do_gameloop (argc=4, argv=0xbfa9f4e4) at src/game.cpp:2154
#21 0x0806b72a in main (argc=4, argv=0xbfa9f4e4) at src/game.cpp:2210

Iurii Chernyi <crab>
Project Member
Tue Mar 24 20:48:07 2009, comment #1:

plus, my screen size is 1400x1050, wesnoth was running in a window.

Iurii Chernyi <crab>
Project Member
Tue Mar 24 20:44:51 2009, original submission:

Launched a test scenario, moved (12,8)-> (10,10)
Happened once, unable to reproduce so far.

./wesnoth-debug -d -t --log-debug=ai,formula_ai

Battle for Wesnoth v1.7.0-svn (33853:34011M)
Started on Tue Mar 24 22:30:16 2009

Automatically found a possible data directory at /home/crab/workspace/programming/cpp/wesnoth

Data directory: /home/crab/workspace/programming/cpp/wesnoth
User configuration directory: /home/crab/.wesnoth-1.7

Checking video mode: 1024x768x16...
setting mode to 1024x768x16
Invalid WML found: Moving to this location is no longer supported... bye bye
wesnoth-debug: src/actions.cpp:2588: void apply_shroud_changes(undo_list&, game_display*, const gamemap&, unit_map&, std::vector<team, std::allocator<team> >&, int): Assertion `unit_itor != units.end()' failed.

Iurii Chernyi <crab>
Project Member


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by gfgtdf (Posted a comment)
  • -unavailable- added by jamit (Posted a comment)
  • -unavailable- added by ai0867 (Posted a comment)
  • -unavailable- added by shadowmaster (Updated the item)
  • -unavailable- added by silene (Posted a comment)
  • -unavailable- added by crab (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 13 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Jan 10 17:06:37 2016gfgtdfOpen/ClosedOpen=>Closed
    Sun Jan 10 17:06:36 2016gfgtdfStatusPostponed=>Fixed
    Sun Dec 15 03:43:25 2013jamitSeverity4 - Important=>3 - Normal
      Assigned tocrab=>jamit
    Tue Dec 3 18:29:54 2013ai0867StatusNone=>Fixed
    Sun Jan 29 21:38:14 2012shadowmasterStatusPostponed=>None
    Tue Nov 17 21:19:47 2009crabStatusIn Progress=>Postponed
    Fri Mar 27 20:35:31 2009crabStatusNone=>In Progress
    Fri Mar 27 20:35:02 2009crabItem GroupGraphics=>Units
      Assigned toNone=>crab
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup