bugBattle for Wesnoth - Bugs: bug #20257, Replay Crash

Show feedback again

bug #20257: Replay Crash

Submitted by:  Robert Schott <wompi>
Submitted on:  Tue Oct 23 12:53:56 2012  
Category: BugSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Replays
Status: FixedPrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: 1.10.4Operating System: MacOS 10.6.8

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)

Sat Jul 19 22:08:04 2014, comment #6:

the code has changed very much and the bug (if ever existed) won't show in this form anymore. Also the given information became useless due to a lot of changes.

However, we didn't find anything that might have caused this bug. So any underlaying bug might still exist (or not), it's also posssible that this was a symptom of a memory corruption from a completely unrelated piece of code.

marking as fixed&closed for the reasons above.

Daniel <gfgtdf>
Project Member
Wed Jun 4 19:57:30 2014, comment #5:

ok in 1.13 the turn_info object is destroyed less often.

Daniel <gfgtdf>
Project Member
Thu Apr 17 00:31:07 2014, comment #4:

ok turn_info s replay_ member was now removed too.

Daniel <gfgtdf>
Project Member
Fri Apr 4 15:54:25 2014, comment #3:

expected_advancements_ was removed in 8617a02a88a38d8fe01ee0a3672d75fc5fe72924.
So this issue shoudn't occur anymore.

(the main intention of the commit was NOT to fix this bug)

Still i didn't find anything wrong with expected_advancements_ that would cause this behaviour, so a possible onderlaying bug still may exist.

Daniel <gfgtdf>
Project Member
Thu Nov 15 12:58:58 2012, comment #2:

Nope i do not work on modified sources. It's from the 1.10.4 subversion checkout.

And as i said it was just a quick guess. If you trace back from playmp_controller::play_network_turn() - where the turn_info object is allocated with the ref of replay_sender_ and compare it with the crash trace it looks like that there is something wrong with the deque. I do not well understand the relations between the network and replay stuff and i just thought it might give you a start to look at. Maybe it is something Mac related idk. Let me know if you need more information or if there is something i could do to help you.

Robert Schott <wompi>
Wed Nov 14 22:10:47 2012, comment #1:

What exactly do you mean by "is not properly initialized within the constructor"? I see expected_advancements_ being explicitly default-constructed in both constructors of replay.

I noticed something odd -- you've listed the declaration of expected_advancements_ as being on line 180 of replay.hpp, yet the source for 1.10.4 has it on line 176. Are you working from modified sources? Could those modifications be responsible for the crash?

J Tyne <jamit>
Project Member
Tue Oct 23 12:53:56 2012, original submission:

Hi Mates.
I'm new to Wesnoth and this bug report might be wrong placed.

After watching some MP games as observer the game crashed sometimes with this log trace:

Process: Wesnoth [40601]
Path: /Volumes/Data/Applications/Wesnoth.app/Contents/MacOS/./Wesnoth
Identifier: org.wesnoth.Wesnoth
Version: 1.10.4 (1.10.4)
Code Type: X86 (Native)
Parent Process: bash [40378]

Date/Time: 2012-10-18 01:31:59.119 +0200
OS Version: Mac OS X 10.6.8 (10K549)
Report Version: 6

Exception Type: EXC_CRASH (SIGSEGV)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 1 Dispatch queue: com.apple.libdispatch-manager

Thread 0: Dispatch queue: com.apple.main-thread

  1. org.wesnoth.Wesnoth 0x00144383 void std::_Destroy<std::_Deque_iterator<map_location, map_location&, map_location*>, std::allocator<map_location> >(std::_Deque_iterator<map_location, map_location&, map_location*>, std::_Deque_iterator<map_location, map_location&, map_location*>, std::allocator<map_location>) + 31

1 org.wesnoth.Wesnoth 0x00144d0a std::deque<map_location, std::allocator<map_location> >::~deque() + 102
2 org.wesnoth.Wesnoth 0x00144d37 replay::~replay() + 21
3 org.wesnoth.Wesnoth 0x00151d0f turn_info::~turn_info() + 51
4 org.wesnoth.Wesnoth 0x0015fb23 playmp_controller::play_network_turn() + 955
5 org.wesnoth.Wesnoth 0x0015ffaa playmp_controller::play_side(unsigned int, bool) + 1148
6 org.wesnoth.Wesnoth 0x00158588 playsingle_controller::play_turn(bool) + 1114
7 org.wesnoth.Wesnoth 0x0015b193 playsingle_controller::play_scenario(std::pair<config::const_child_iterator, config::const_child_iterator> const&, bool) + 2777
8 org.wesnoth.Wesnoth 0x00163799 play_game(display&, game_state&, config const&, io_type_t, bool) + 11611
9 org.wesnoth.Wesnoth 0x001aad39 enter_wait_mode(game_display&, config const&, mp::chat&, config&, bool) + 395
10 org.wesnoth.Wesnoth 0x001af763 mp::start_client(game_display&, config const&, std::string const&) + 16595
11 org.wesnoth.Wesnoth 0x0061af32 game_controller::play_multiplayer() + 1674
12 org.wesnoth.Wesnoth 0x00290225 SDL_main + 3321

After looking at the source code file 'replay.hpp' it looks like that the member:

180: std::deque<map_location> expected_advancements_;

is not properly initialized within the constructor. And if the game tries to 'deallocate' the replay object the game crashes with the above trace.
This is just a quick guess so better do not count on that to much, but maybe it helps.

Robert Schott <wompi>


(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 shadowmaster (Updated the item)
  • -unavailable- added by gfgtdf (Posted a comment)
  • -unavailable- added by jamit (Posted a comment)
  • -unavailable- added by wompi (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 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat Jul 19 22:08:04 2014gfgtdfStatusWont Fix=>Fixed
    Wed Jun 4 19:57:30 2014gfgtdfStatusReady For Test=>Wont Fix
    Wed Apr 23 01:00:38 2014shadowmasterStatusWorks For Me=>Ready For Test
    Thu Apr 17 00:31:07 2014gfgtdfStatusNone=>Works For Me
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup