Crash on startup: "Invalid window"

[cronvel]

Hi,
It's been few months since I've played this game. I just downloaded the game again, removed the ~/.citadel folder to start over with a clean install, launched the game and....... crash! The console tells me "invalid window". Doh!

$ ./run.sh 
INFO: main.cpp:467 : Anura engine version 1.4
INFO: main.cpp:506 : Default Tile Size: 16
INFO: main.cpp:507 : Default Tile Scale: 2
INFO: main.cpp:509 : Build Options:
INFO: main.cpp:511 :     isomap
INFO: main.cpp:511 :     lua
INFO: main.cpp:511 :     save_png
INFO: main.cpp:511 :     sdl2
INFO: main.cpp:511 :     svg
INFO: preferences.cpp:583 : SET PREFERENCES PATH: ~/.citadel/
INFO: preferences.cpp:583 : SET PREFERENCES PATH: ~/.citadel/
INFO: main.cpp:612 : ARGS: --module=citadel
INFO: main.cpp:612 : ARGS: --utility=update_launcher
INFO: preferences.cpp:637 : EXPAND DATA PATHS
INFO: main.cpp:746 : Preferences dir: /home/cedric/.citadel/
INFO: module.cpp:1172 : Requesting module 'citadel'
INFO: http_client.cpp:65 : http_client::send_request(this = 0x1c11010 @0 method_path = GET /module_data/citadel request.size() = 0 num_retries = 0 attempt_num = 1)

INFO: module.cpp:1172 : Requesting module 'anura_linux'
INFO: http_client.cpp:65 : http_client::send_request(this = 0x1c21ed0 @0 method_path = GET /module_data/anura_linux request.size() = 0 num_retries = 0 attempt_num = 1)

INFO: auto_update_window.cpp:570 : Requesting update to module from server...
CRITICAL: WindowManager.cpp:284 ASSERTION FAILED: Failed to create renderer: Invalid window

CRITICAL: 
---
CRITICAL: stack trace:
CRITICAL:   ./bin/anura : KRE::SDLWindow::createWindow()+0x1a69
CRITICAL:   ./bin/anura : KRE::WindowManager::createWindow(std::shared_ptr<KRE::Window>)+0x1a
CRITICAL:   ./bin/anura : KRE::WindowManager::createWindow(int, int, variant const&)+0xf8
CRITICAL:   ./bin/anura : auto_update_window::create_window()+0x399
CRITICAL:   ./bin/anura() [0xa24162]
CRITICAL:   ./bin/anura : UTILITY_update_launcher(std::vector<std::string, std::allocator<std::string> > const&)+0x337
CRITICAL:   ./bin/anura : test::run_utility(std::string const&, std::vector<std::string, std::allocator<std::string> > const&)+0x126
CRITICAL:   ./bin/anura : main()+0x2e36
CRITICAL:   /lib64/libc.so.6 : __libc_start_main()+0xea
CRITICAL:   ./bin/anura() [0x6abb55]
CRITICAL: ---
./run.sh: line 8:  6923 Aborted                 (core dumped) LIBGL_DRI3_DISABLE=1 LD_LIBRARY_PATH=./bin/:$LD_LIBRARY_PATH ./bin/anura --module=citadel --utility=update_launcher --update-module=true --update-anura=true --anura=anura_linux --anura-exe=./anura.sh --args --module=citadel $@

I'm using an up to date Fedora 26.
Other SDL-based games run fine.
The game used to work on my setup (but it was probably before the Fedora 26 system upgrade).

[lupoDharkael]

Same here in Fedora 26 KDE

[Szunti]

Got this on Archlinux, but building my own anura solved it.

[ghost]

Maybe related, maybe not:

#talk <CansecoGPC> Strange error: I can start the game at 1920x1080 in my desktop, but on 1366x768 on my laptop it refuses to start
#talk <CansecoGPC> WindowManager.cpp:284 ASSERTION FAILED: Failed to create renderer: Invalid window

[ghost]

Evidence shows a desktop PC with 1080px of display height running Arch and X11 but not KDE and not Gnome is affected.

[ghost]

Today a player using the Lutris distribution and crashing with this message kindly replaced the anura of the auto updater by the latest build, so instead of crashing in Invalid window crashed at this line https://github.com/anura-engine/anura/blob/b682cfd2dc7dd88f24a5f785dd0dc8e4199c68d3/src/kre/WindowManager.cpp#L278
printing 805240832, 805240832, 800, 600 / wnd_flags = 2.

My Debian output for x, y and wnd_flags is the same. The small width and height are explained because of the auto update is configured that way. When I forced trunk Anura into starting a download of citadel from The Argent Lark, it is literally having the same values there, but working OK.

So I think of continuing anura-engine/anura@b682cfd with more and more logged info tracing back.

Another strategy could be to try to find something wrong in an ltrace or strace log, or even in a valgrind output, or a gdb debug session.

I can't reproduce the crash without at least a new GNU/Linux install that I can't afford. I don't know if davewx7 can fix this without reproducing it before, so I am labeling help wanted.

[Szunti]

Can this be the bug here? Already fixed in SDL, would answer why I don't have it when linking with archlinux's libSDL.
https://bugzilla.libsdl.org/show_bug.cgi?id=1428

[Szunti]

the huge number is the constant SDL_WINDOWPOS_CENTERED, not a bug

[ghost]

Can this be the bug here?

I don't know. But that seems old enough to be unlikely..?

[...] would answer why I don't have it when linking with archlinux's libSDL. [...]

I don't know. I suppose that could have an easier answer if the inner structure of the auto updating AA distribution was not:

$ ls -1 /PATH/TO/AA_LINUX_20180404/bin/*SDL*
/PATH/TO/AA_LINUX_20180404/bin/libSDL2-2.0.so.0
/PATH/TO/AA_LINUX_20180404/bin/libSDL2_image-2.0.so.0
/PATH/TO/AA_LINUX_20180404/bin/libSDL2_mixer-2.0.so.0
/PATH/TO/AA_LINUX_20180404/bin/libSDL2_ttf-2.0.so.0
$ _

But something more similar to this other, in the sense it saves the full version numbers (don't parse ls -l outputs, that's a bad practice):

$ ls -l $(find /usr/ | grep libSDL) | awk '{ if ($10 == "") { print $9 " is a l\
ibrary"; } else { print $9 " is a symlink\n  " $10 " to " $11 } }'
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 is a symlink
  -> to libSDL-1.2.so.0.11.4
/usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0.11.4 is a library
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so is a symlink
  -> to libSDL2-2.0.so.0.4.1
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0 is a symlink
  -> to libSDL2-2.0.so.0.4.1
/usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.4.1 is a library
/usr/lib/x86_64-linux-gnu/libSDL2.a is a library
/usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so is a symlink
  -> to libSDL2_image-2.0.so.0.0.1
/usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so.0 is a symlink
  -> to libSDL2_image-2.0.so.0.0.1
/usr/lib/x86_64-linux-gnu/libSDL2_image-2.0.so.0.0.1 is a library
/usr/lib/x86_64-linux-gnu/libSDL2_image.a is a library
/usr/lib/x86_64-linux-gnu/libSDL2_image.so is a symlink
  -> to libSDL2_image-2.0.so.0.0.1
/usr/lib/x86_64-linux-gnu/libSDL2main.a is a library
/usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so is a symlink
  -> to libSDL2_mixer-2.0.so.0.0.1
/usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0 is a symlink
  -> to libSDL2_mixer-2.0.so.0.0.1
/usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0.0.1 is a library
/usr/lib/x86_64-linux-gnu/libSDL2_mixer.a is a library
/usr/lib/x86_64-linux-gnu/libSDL2_mixer.so is a symlink
  -> to libSDL2_mixer-2.0.so.0.0.1
/usr/lib/x86_64-linux-gnu/libSDL2.so is a symlink
  -> to libSDL2-2.0.so.0.4.1
/usr/lib/x86_64-linux-gnu/libSDL2_test.a is a library
/usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so is a symlink
  -> to libSDL2_ttf-2.0.so.0
/usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so.0 is a symlink
  -> to libSDL2_ttf-2.0.so.0.14.0
/usr/lib/x86_64-linux-gnu/libSDL2_ttf-2.0.so.0.14.0 is a library
/usr/lib/x86_64-linux-gnu/libSDL2_ttf.a is a library
/usr/lib/x86_64-linux-gnu/libSDL2_ttf.so is a symlink
  -> to libSDL2_ttf-2.0.so.0.14.0
/usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0 is a symlink
  -> to libSDL_image-1.2.so.0.8.4
/usr/lib/x86_64-linux-gnu/libSDL_image-1.2.so.0.8.4 is a library
$ _

If it is a mainly (or plainly) SDL bug or oddity, you could build Anura with that exact SDL version and see if that reproduces, if you could knew which exact versions the auto updater uses.

And there is yet a little bit more than that. Imagine this is a bug in a particular SDL version. Fixed in newer versions. Imagine the current AA auto updating distribution uses a safe SDL version. If in the past there was an AA auto updating distribution using the problematic SDL version, there might exist third parties still redistributing that old AA auto updating distribution. This player uses the Lutis Open Gaming Platform. We may know how often Lutis rebuilds their packaging of AA (by fetching the current auto updating distribution in force, I've been told), but we may not know. I don't know.

I could draw the conclusions:

• If possible, better to include over explaining symlink chains of libraries, if the build toolchain makes it available.
• Make sure the auto updating distribution is tagging itself as much as possible. By not tagging anything there are the timestamps though. As long as the auto updating distribution keeps being a sparsely rebuilt project, that's more than enough.

Cheers,

[Szunti]

I don't know. But that seems old enough to be unlikely..?

the runtime dir has libicuuc.so.48 which is from 2012. The SDL2 bug is from 2012 too.

[ghost]

the runtime dir has libicuuc.so.48 which is from 2012. The SDL2 bug is from 2012 too.

With this point about ICU looks very solid to me.

Hints to a required update to be applied somewhere at the environment under which the build toolchain of the auto updater stacks.

My reasoning of "minor version and revision probably not enough detailed to know for sure" would still apply in some degree though, but that's just an idea for enhancement, not the fix...