[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Update of bug #24022 (project wesnoth): Open/Closed:Open => Closed ___ Reply to this item at: ___ Message

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Update of bug #24022 (project wesnoth): Status:None => Fixed Assigned to:None => wedge009 Release: master => 1.13.1+dev

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #10, bug #24022 (project wesnoth): Created PR #559 in response to gfgtdf's suggestion. ___ Reply to this item at: ___ Message sent via/by Gna!

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #7, bug #24022 (project wesnoth): Since there seem to be multiple bugs with planned recuits (see for example this one https://www.mail-archive.com/wesnoth-bugs@gna.org/msg24885.html but iirc there are also others) i wonder whether we should just disable planned recruits.

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #8, bug #24022 (project wesnoth): Also 'master' is not a good value for the 'relese' field, for example when later 'master' is 1.15.9 or something noone will know with which version this was reproduced. ___ Reply to this

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #9, bug #24022 (project wesnoth): I know that, but in this particular case I don't know in which version it started. I should have mentioned in the original report that this was on 1.13.1+dev. There do seem to be problems with planned recruits because they're don't seem to be

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #5, bug #24022 (project wesnoth): > fake_unit_manager's deque appears to be valid Why do you think this? ___ Reply to this item at: ___

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #6, bug #24022 (project wesnoth): Because it could still be read by the debugger and its size was 0 - which is correct. After the ~recruit() was done, but before ~fake_unit_ptr() is called, the debugger flags the deque elements as 'cannot be read from memory' and its size

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #4, bug #24022 (project wesnoth): This is very strange. Stepping into the recruit's (empty) destructor, the fake_unit_ptr's fake_unit_manager's deque appears to be valid. But after ~recruit() is complete, fake_unit_manager's deque appears to have already been destroyed, but then

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #3, bug #24022 (project wesnoth): Only that there's an access violation reading a memory location. The crash happens while destroying the fake_unit_ptr, but the access violation happens inside the std libraries, which I find hard to read. Hopefull I got the mark-up correct,

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #2, bug #24022 (project wesnoth): Does it provide any additional information about the crash? It's possible the MSVC++ runtime is detecting something that GNU libstdc++ would normally ignore and cause harder to debug situations later on (e.g. memory corruption).

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

Follow-up Comment #1, bug #24022 (project wesnoth): Correction: this seems to be on Windows only. Possibly even MSVC-build only, the crash is within the MS implementation of the std::deque object of fake_unit_manager::remove_temporary_unit().

[Wesnoth-bugs] [bug #24022] Crash on Quit Scenario With Planned Recruits Present

URL: Summary: Crash on Quit Scenario With Planned Recruits Present Project: Battle for Wesnoth Submitted by: wedge009 Submitted on: Wed 04 Nov 2015 03:32:44 PM AEDT Category: Bug