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 24 Mar 2009 08:44:51 PM UTC  
 
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Units
Status: PostponedPrivacy: Public
Assigned to: J Tyne <jamit>Open/Closed: Open
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 15 Dec 2013 03:43:25 AM UTC, 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 03 Dec 2013 06:29:54 PM UTC, 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 17 Nov 2009 09:19:47 PM UTC, 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 01 May 2009 07:26:27 PM UTC, 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 26 Mar 2009 09:20:26 PM UTC, 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 24 Mar 2009 11:57:57 PM UTC, comment #4:

The problematic code fragments are:

src/actions.cpp:2413
---
event_mutated |= game_events::pump();
ui = units.find(steps.back());

if(undo_stack != NULL) {
if(event_mutated || should_clear_stack || ui == units.end())
apply_shroud_changes(*undo_stack,disp,map,units,teams,team_num);
undo_stack->clear();
} 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)){
units->erase(un);
unit_mutations++;
}
}
---

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 24 Mar 2009 09:56:46 PM UTC, comment #3:

how-to-reproduce:
--
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 24 Mar 2009 09:28:12 PM UTC, 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 24 Mar 2009 08:48:07 PM UTC, comment #1:

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

Iurii Chernyi <crab>
Project Member
Tue 24 Mar 2009 08:44:51 PM UTC, 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.
Abort

Iurii Chernyi <crab>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

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 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.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 15 Dec 2013 03:43:25 AM UTCjamitSeverity4 - Important=>3 - Normal
      StatusFixed=>Postponed
      Assigned tocrab=>jamit
      Open/ClosedClosed=>Open
    Tue 03 Dec 2013 06:29:54 PM UTCai0867StatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Sun 29 Jan 2012 09:38:14 PM UTCshadowmasterStatusPostponed=>None
    Tue 17 Nov 2009 09:19:47 PM UTCcrabStatusIn Progress=>Postponed
    Fri 27 Mar 2009 08:35:31 PM UTCcrabStatusNone=>In Progress
    Fri 27 Mar 2009 08:35:02 PM UTCcrabItem GroupGraphics=>Units
      Assigned toNone=>crab
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup