Bug#970520: fixed in wesnoth-1.14 1:1.14.15-1

2021-01-03 Thread Max Minenko
Yes, the issue is fixed now (with the version 1.14.15 installed). The game starts normally again, as it should. On Fri, 01 Jan 2021 22:51:54 + Debian FTP Masters < ftpmas...@ftp-master.debian.org> wrote: > Source: wesnoth-1.14 > Source-Version: 1:1.14.15-1 > Done: Rhonda D'Vine > > We believe

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

2020-11-15 Thread Gerardo Esteban Malazdrewicz
Package: wesnoth Version: 1:1.14.13-1 Followup-For: Bug #970520 X-Debbugs-Cc: gera...@malazdrewicz.com.ar Dear Maintainer, Patch 99wolfssl-options attached adding #include to affected files: src/build_info.cpp src/hash.cpp src/preferences/credentials.cpp src/server/user_handler.cpp This

Bug#970520: confirm workaround

2020-10-07 Thread Bolan Moonward
On Tue, 29 Sep 2020 14:58:36 +0200 Benedikt Hallinger 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 libwolf

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

2020-10-02 Thread Felix Lechner
Hi Bernhard, On Fri, Oct 2, 2020 at 8:06 AM Bernhard Übelacker 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

Bug#970520: confirm workaround

2020-10-02 Thread Adrian Heine
This has been caused by ba2477a1915a0e13de0fe09f4ac1ea0f65b13289, i. e. switching to wolfssl. It is fixed by putting > #include before the openssl includes (probably in src/hash.cpp).

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

2020-10-02 Thread Bernhard Übelacker
Dear Maintainer, I could reproduce this stack smashing inside a testing amd64 VM. The stack canary gets overwritten in the stack below. It looks like there is a disagreement of wesnoth and wolfssl in the size of sha/hasher wc_Sha/WOLFSSL_SHA_CTX, the first allocates 112 bytes, the latter thinks i

Bug#970520: confirm workaround

2020-09-29 Thread Benedikt Hallinger
Confirming $ wesnoth --nocache works here too. But what is causing this? Is this an upstream bug? Or one debian introduces?

Bug#970520:

2020-09-26 Thread Max Minenko
Oh, many thanks Davide! (At least *someone* cares...) I can start and play the game that way.

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

2020-09-25 Thread Davide Prina
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

Bug#970520: The same bug

2020-09-23 Thread Max Minenko
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/USE

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

2020-09-17 Thread Max Hofer
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/