Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1025482 > unrolled thread

Bug#970520: wesnoth: Crash on starting wesnoth - stack smash detected

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#970520: wesnoth: Crash on starting wesnoth - stack smash detected Max Hofer <max-hofer@gmx.net> - 2020-09-17 22:50 +0200
    Bug#970520: The same bug Max Minenko <maksym.minenko@gmail.com> - 2020-09-23 17:00 +0200
    Bug#970520: wesnoth: Crash on starting wesnoth - stack smash detected Davide Prina <davide.prina@gmail.com> - 2020-09-25 18:10 +0200
    Bug#970520:  Max Minenko <maksym.minenko@gmail.com> - 2020-09-26 18:20 +0200
    Bug#970520: confirm workaround Benedikt Hallinger <beni@hallinger.org> - 2020-09-29 15:10 +0200
      Bug#970520: confirm workaround Adrian Heine <debian@adrianheine.de> - 2020-10-02 23:20 +0200
      Bug#970520: confirm workaround Bolan Moonward <bolan@voland0.xyz> - 2020-10-07 21:30 +0200
    Bug#970520: wesnoth: Crash on starting wesnoth - stack smash detected Felix Lechner <felix.lechner@lease-up.com> - 2020-10-03 03:40 +0200

#1025482 — Bug#970520: wesnoth: Crash on starting wesnoth - stack smash detected

Package: wesnoth
Version: 1:1.14.13-1
Severity: important

Dear Maintainer,

when I start wesnoth it crashed with follwoing output:


-------- START OF TERMINAL OUTPUT ---------
Battle for Wesnoth v1.14.13
Started on Thu Sep 17 22:33:45 2020


Data directory:               /usr/share/games/wesnoth/1.14
User configuration directory: /home/USER/.config/wesnoth-1.14
User data directory:          /home/USER/.config/wesnoth-1.14
Cache directory:              /home/USER/.config/wesnoth-1.14/cache

Setting mode to 1280x720
*** stack smashing detected ***: terminated
Abgebrochen
-------- END OF TERMINAL OUTPUT ------------

My .xsession file does not contain much information.

--------- START .xsession ----------------
powerdevil: Scheduling inhibition from ":1.15" "My SDL application" with cookie 5 and reason "Playing a game"
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37711, resource id: 37752062, major code: 3 (GetWindowAttributes), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 37712, resource id: 37752062, major code: 14 (GetGeometry), minor code: 0
powerdevil: Releasing inhibition with cookie  5
powerdevil: It was only scheduled for inhibition but not enforced yet, just discarding it
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37838, resource id: 79691790, major code: 15 (QueryTree), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 37844, resource id: 79691790, major code: 18 (ChangeProperty), minor code: 0
OpenGL vendor string:                   Intel Open Source Technology Center
OpenGL renderer string:                 Mesa DRI Intel(R) HD Graphics 4600 (HSW GT2)
OpenGL version string:                  3.0 Mesa 20.1.8
OpenGL shading language version string: 1.30
Driver:                                 Intel
GPU class:                              Unknown
OpenGL version:                         3.0
GLSL version:                           1.30
Mesa version:                           20.1.8
X server version:                       1.20.9
Linux kernel version:                   5.8
Requires strict binding:                yes
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
BlurConfig::instance called after the first use - ignoring
DesktopGridConfig::instance called after the first use - ignoring
KscreenConfig::instance called after the first use - ignoring
PresentWindowsConfig::instance called after the first use - ignoring
SlideConfig::instance called after the first use - ignoring
SlidingPopupsConfig::instance called after the first use - ignoring
ZoomConfig::instance called after the first use - ignoring
powerdevil: Enforcing inhibition from ":1.15" "My SDL application" with cookie 5 and reason "Playing a game"
powerdevil: By the time we wanted to enforce the inhibition it was already gone; discarding it
--------- END .xsession ----------------

I haven't found valuable information in any other log file on my system.

I run KDE with sddm.


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT:de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages wesnoth depends on:
ii  wesnoth-1.14       1:1.14.13-1
ii  wesnoth-1.14-data  1:1.14.13-1

wesnoth recommends no packages.

wesnoth suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#1026161 — Bug#970520: The same bug

[Multipart message — attachments visible in raw view] — view raw

My situation is identical:

--------------------------------------------------------------------------------
minemax@maxPC:~$ wesnoth
Battle for Wesnoth v1.14.13
Started on Wed Sep 23 17:44:51 2020


Data directory:               /usr/share/games/wesnoth/1.14
User configuration directory: /home/USER/.config/wesnoth-1.14
User data directory:          /home/USER/.config/wesnoth-1.14
Cache directory:              /home/USER/.config/wesnoth-1.14/cache

Setting mode to 1920x1080
*** stack smashing detected ***: terminated
Aborted

[toc] | [prev] | [next] | [standalone]

#1026405

The game can be started with the following command:

$ wesnoth --nocache

I'm not a Wesnoth player, so I don't know if all work correctly after it 
start.

Ciao
Davide

[toc] | [prev] | [next] | [standalone]

#1026520 — Bug#970520:

[Multipart message — attachments visible in raw view] — view raw

Oh, many thanks Davide! (At least *someone* cares...)
I can start and play the game that way.

[toc] | [prev] | [next] | [standalone]

#1026921 — Bug#970520: confirm workaround

Confirming $ wesnoth --nocache works here too.

But what is causing this? Is this an upstream bug? Or one debian 
introduces?

[toc] | [prev] | [next] | [standalone]

#1027332 — Bug#970520: confirm workaround

This has been caused by ba2477a1915a0e13de0fe09f4ac1ea0f65b13289, i. e. 
switching to wolfssl. It is fixed by putting

 > #include <wolfssl/options.h>

before the openssl includes (probably in src/hash.cpp).

[toc] | [prev] | [next] | [standalone]

#1027828 — Bug#970520: confirm workaround

On Tue, 29 Sep 2020 14:58:36 +0200 Benedikt Hallinger 
<beni@hallinger.org> wrote:
 > Confirming $ wesnoth --nocache works here too.
 >
 > But what is causing this? Is this an upstream bug? Or one debian
 > introduces?

Nobody directly answered your question, so...  It was introduced by the 
Debian builder, using libwolfssl, instead of openssl, due to licensing 
issues.

[toc] | [prev] | [next] | [standalone]

#1027343

Hi Bernhard,

On Fri, Oct 2, 2020 at 8:06 AM Bernhard Übelacker <bernhardu@mailbox.org> wrote:
>
> @Felix Lechner: Hope it is ok to add you in CC?

Absolutely. I was already in touch with wolfSSL upstream, who process
my tickets at their highest support level. They tasked two employees
with analyzing the backtrace but we called off the effort when it
turned out to be more likely a porting error.

I have not looked at commit ba2477a1, but the official porting method is.

1. Convert all includes for <openssl/*.h> to <wolfssl/openssl/*.h>
2. Before such includes, add <wolfssl/options.h>

The procedure is also described in the wolfSSL Debian package [1].
Thanks to Adrian Heine for locating the issue so quickly!

Kind regards
Felix Lechner (wolfSSL maintainer)

[1] https://sources.debian.org/src/wolfssl/4.5.0+dfsg-4/debian/README.Debian/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web