Open cronvel opened 6 years ago
Same here in Fedora 26 KDE
Got this on Archlinux, but building my own anura solved it.
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
Evidence shows a desktop PC with 1080px of display height running Arch and X11 but not KDE and not Gnome is affected.
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 https://github.com/anura-engine/anura/commit/b682cfd2dc7dd88f24a5f785dd0dc8e4199c68d3 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.
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
the huge number is the constant SDL_WINDOWPOS_CENTERED, not a bug
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:
Cheers,
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.
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...
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!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).