Wesnoth 1.16.6 Flatpak crashes after recruiting unit when running under Wayland

[danrobinson78]

Noticed this with both the Flathub and Fedora registries although the bug appears slightly differently on both.

With Flathub on 1.16.6, the recruited unit appears, and then the gui disappears but the process doesn't end, and I get an error message that says Error sending request: Broken pipe.

The Fedora registry has 1.17.7, and on that the crash occurs before the unit appears with an error message is /usr/include/c++/12/bits/stl_vector.h:1230: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::back() [with _Tp = gui2::window*; _Alloc = std::allocator<gui2::window*>; reference = gui2::window*&]: Assertion '!this->empty()' failed.

Now that I'm writing this there's a chance that it should be two separate issues but they seem both isolated to the Flatpak installs since I don't have the issue when installed natively.

[Pentarctagon]

Please provide the relevant information list at https://forums.wesnoth.org/viewtopic.php?t=25660

[soliton-]

Issues about 1.17.7 are not that useful since we're at 1.17.9. If you want to try the dev version you can try the nightly flatpak.

On 1.16.6 do you have addons installed? If so which ones? Are you using wayland?

[danrobinson78]

On 1.16.6 I am on Wayland. I can definitely check on X and see if it still happens. But no add-ons, just directly off of Flathub.

And then for 1.17 I'll try that and if it does still exist I'll try building the latest version outside Flatpak as well.

Might be tomorrow before I get a chance to look at any of it though.

[danrobinson78]

Ok I actually had some time to test stuff. RE: 1.17 the nightly build didn't have an issue at all, so we can assume that that's fixed. RE: 1.16.6 it does crash under Wayland, but on an X11 session it seems to work properly. So I updated the bug title to reflect the issue.

Here's the full build info: The Battle for Wesnoth version 1.16.6 x86_64 Running on Freedesktop.org SDK 22.08 (Flatpak runtime) x86_64 Distribution channel: Flatpak

Game paths

Data dir: /app/share/wesnoth User config dir: /home/USER/.var/app/org.wesnoth.Wesnoth/config/wesnoth User data dir: /var/home/USER/.var/app/org.wesnoth.Wesnoth/data/wesnoth/1.16 Saves dir: /var/home/USER/.var/app/org.wesnoth.Wesnoth/data/wesnoth/1.16/saves Add-ons dir: /var/home/USER/.var/app/org.wesnoth.Wesnoth/data/wesnoth/1.16/data/add-ons Cache dir: /home/USER/.var/app/org.wesnoth.Wesnoth/cache/wesnoth

Libraries

Boost: 1.80 Lua: 5.4.2 OpenSSL/libcrypto: 3.0.0e-dev (runtime 3.0.0g-dev) Cairo: 1.16.0 (runtime 1.16.0) Pango: 1.50.9 (runtime 1.50.11) SDL: 2.24.0 (runtime 2.24.0) SDL_image: 2.6.2 (runtime 2.6.2) SDL_mixer: 2.6.0 (runtime 2.6.0)

Features

Lua console completion: yes D-Bus notifications back end: yes

Current video settings

SDL video drivers: [x11] wayland dummy evdev Window size: 1920x1080 Screen refresh rate: 60 Screen dots per inch: 141.767441x142.134720 Screen dpi scale factor: 1.476744x1.480570

Current audio settings

SDL audio drivers: [pulseaudio] disk dummy Number of channels: 2 Output rate: 44100 Hz Sample format: signed 16 bit little-endian Sample size: 1024 bytes

Installed add-ons

No add-ons installed.

If it helps I'm running on Plasma, although I think I remember this happening under Gnome as well. Should be pretty easy to reproduce, just install the stable build from Flathub, run it in a Wayland session, and then try to recruit your first unit (I was trying under Northern Rebirth but any campaign seems to trigger it).

And like I said, if I run it from a terminal, the last thing I get is Error sending request: Broken pipe and the game window disappears, but I have to manually Ctrl+C to cause the app to return.

[odanoburu]

Hello, I can confirm I have the same problem on 1.17.10 (which I was packaging in the hopes of removing this bug from the Fedora repositories). I can also confirm it doesn't happen on X. There is also a bug report in Fedora's bugzilla, with a backtrace and other information. The error I get is:

Setting mode to 1920x1080
20221123 12:49:11 warning general: no location found for 'data/add-ons/Start_of_the_War/translations', skipping textdomain
Checking lua scripts... ok
/usr/include/c++/12/bits/stl_vector.h:1230: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::back() [with _Tp = gui2::window*; _Alloc = std::allocator<gui2::window*>; reference = gui2::window*&]: Assertion '!this->empty()' failed.
fish: Job 1, 'wesnoth' terminated by signal SIGABRT (Abort)

After starting a campaign and recruiting some units (the number of units recruited to trigger the bug seems to be non-deterministic).

Information

The Battle for Wesnoth version 1.17.10 (18bd2ff-Modified) x86_64 Running on Fedora Linux 37 (Workstation Edition) x86_64 Distribution channel: Default

Game paths

Data dir: /usr/share/wesnoth User config dir: /home/USER/.config/wesnoth User data dir: /home/USER/.local/share/wesnoth/1.17 Saves dir: /home/USER/.local/share/wesnoth/1.17/saves Add-ons dir: /home/USER/.local/share/wesnoth/1.17/data/add-ons Cache dir: /home/USER/.cache/wesnoth Logs dir: /home/USER/.local/share/wesnoth/1.17/logs

Libraries

Boost: 1.78 Lua: 5.4.4 OpenSSL/libcrypto: 3.0.0e-dev (runtime 3.0.0e-dev) Cairo: 1.17.6 (runtime 1.17.6) Pango: 1.50.12 (runtime 1.50.12) SDL: 2.24.0 (runtime 2.24.0) SDL_image: 2.6.1 (runtime 2.6.1) SDL_mixer: 2.0.4 (runtime 2.0.4)

Features

Lua console completion: yes D-Bus notifications back end: yes

Current video settings

SDL video drivers: wayland [x11] KMSDRM dummy evdev Window size: 1920x1080 Game canvas size: 1920x1080 Final render target size: 1920x1080 Screen refresh rate: 60

Current audio settings

SDL audio drivers: [pulseaudio] alsa jack pipewire dsp Number of channels: 2 Output rate: 44100 Hz Sample format: signed 16 bit little-endian Sample size: 1024 bytes

Installed add-ons

A_New_Order: 1.4.1 Akladian_Music: 1.0.1 Start_of_the_War: 1.0.4.2 Struggle_For_Freedom: 1.0.6.6 War_of_Legends: 1.2.7.20

[Pentarctagon]

So the stack trace refers to the line https://github.com/wesnoth/wesnoth/blob/5ffa031e8e79b0e1e4b1cfb02302030ff6bb02b6/src/gui/core/timer.cpp#L222 with the last reference to Wesnoth's code being https://github.com/wesnoth/wesnoth/blob/5ffa031e8e79b0e1e4b1cfb02302030ff6bb02b6/src/gui/widgets/text_box_base.cpp#L319

So it looks like the issue is that the cursor state is attempting to be updated as transparent or opaque (text cursor blinking) when the textbox state is not ENABLE or DISABLED (so either FOCUSED or HOVERED) and the open_window_stack https://github.com/wesnoth/wesnoth/blob/5ffa031e8e79b0e1e4b1cfb02302030ff6bb02b6/src/gui/core/event/handler.hpp#L265 is empty. Calling back() on an empty vector is then undefined behavior.

At a glance, the fix would be to change get_window() != open_window_stack.back() to open_window_stack.size() != 0 && get_window() != open_window_stack.back()

@Vultraz @CelticMinstrel any thoughts?

[CelticMinstrel]

While that sounds like it would prevent the crash, the fact that this code is running at all when the open window stack is empty also seems suspect.

[Pentarctagon]

Yeah, I was wondering about that. Off the top of my head I'd wonder if maybe the timer is left running after the window closes or something like that, but I don't know this code at all (also not sure how to debug a flatpak app).

[CelticMinstrel]

Off the top of my head I'd wonder if maybe the timer is left running after the window closes or something like that

I was thinking along similar lines, yes.

[odanoburu]

(also not sure how to debug a flatpak app).

just to clarify, I was running wesnoth as packaged by Fedora, not as a flatpak. I guess you only need Wayland and any form of wesnoth for the problem to arise. I'd git bisect to narrow down when the problem started if it didn't take ages for my laptop to compile wesnoth…

do you think it's worth it to submit a patched version to Fedora while a new wesnoth release is not made? the current version on the Fedora repositories also has the 'no undo' bug which has been fixed, so it should be fixed asap, I'd say…

[Pentarctagon]

Can you confirm whether the quick fix I posted above prevents the crash?

[odanoburu]

yep, can confirm!