search

wesnoth / wesnoth

An open source, turn-based strategy game with a high fantasy theme.
https://www.wesnoth.org/
GNU General Public License v2.0
5.31k stars 995 forks source link

Wesnoth (master) does not start #9007

Open doofus-01 opened 1 week ago

doofus-01 commented 1 week ago

Game and System Information

Libraries

Boost: 1.75 Lua: 5.4.6 OpenSSL/libcrypto: 3.0.0h-dev (runtime 3.0.0h-dev) libcurl: 8.0.1 (runtime 8.0.1) Cairo: 1.16.0 (runtime 1.16.0) Pango: 1.50.4 (runtime 1.50.4) SDL: 2.30.3 (runtime 2.30.3) SDL_image: 2.8.2 (runtime 2.8.2) SDL_mixer: 2.8.0 (runtime 2.8.0)

Features

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

Current video settings

SDL video drivers: [x11] wayland KMSDRM offscreen dummy evdev Window size: 1819x1110 Game canvas size: 1819x1110 Final render target size: 1819x1110 Screen refresh rate: 60 Screen dpi: 162.56x161.36 Renderer: opengl (hw) Maximum texture size: 32768x32768 VSync: on

Current audio settings

SDL audio drivers: [pulseaudio] alsa pipewire dsp 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.

Description of the bug

Starting from CLI, wesnoth does not open a window to the main menu, it just hangs until process is canceled.

Battle for Wesnoth v1.19.0+dev (6d6bb8dc0c3-Modified) x86_64
Started on Sun Jun 16 17:50:28 2024

Automatically found a possible data directory at: /home/USER/West/dev/wesnoth
20240616 17:50:28 error deprecation: --userdata-dir=<relative path> has been deprecated and will be removed in version 1.17.0.; Use absolute paths. Relative paths are deprecated because they are interpreted relative to $HOME
20240616 17:50:28 error deprecation: --userdata-dir=<relative path> has been deprecated and will be removed in version 1.17.0.; Use absolute paths. Relative paths are deprecated because they are interpreted relative to $HOME

1809af8cdf8 works ae8556a4c6 doesn't

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

Pentarctagon commented 1 week ago

If you don't use --userdata-dir does it work?

doofus-01 commented 1 week ago

I didn't use that option, it was automatic(?)

Pentarctagon commented 1 week ago

Can you build with the most commit (7ac6a788936b5055800efc981f0a6303709e55ba) and see if that fixed anything? I don't get that issue (also on Linux), but the preferences refactor is the most likely culprit in the commit range you mentioned.

doofus-01 commented 1 week ago

I tried, but it's no different from https://github.com/wesnoth/wesnoth/commit/6d6bb8dc0c3c0fd8c13dd74da28bf49b1a435751

EDIT: I don't know if it's relevant, or just a coincidence, but recent versions that did work only have one error deprecation: --userdata-dir=<relative path> has been deprecated and will be removed in version 1.17.0.; Use absolute paths. Relative paths are deprecated because they are interpreted relative to $HOME The failing versions have two of those messages.

Pentarctagon commented 1 week ago

I mean, if you're not specifying that argument then it's weird you'd be seeing that at all. What's the command being run on the command line, specifically?

doofus-01 commented 1 week ago

I just use ./wesnoth from the base wesnoth folder, since I didn't install it. The contents of my .scons-option-cache are

default_targets = 'wesnoth,wesnothd'
version_suffix = '1_19'
cxxtool = 'g++-12'

I can't compile without the last entry.

Pentarctagon commented 1 week ago

Weird, definitely can't reproduce the issue myself then. Would you be able to compile at commit 81a1ef260d34991b74d2081f8324e88e8fbf36a0, and if the issue isn't present then compile at commit 971073055e2487560940790cc340d91cd8d8e8df and check if it's started happening or not?

doofus-01 commented 1 week ago

81a1ef260d3 works (and I only get one error deprecation: --userdata-dir=<relative path> ...). I have to sign off, so I can't check https://github.com/wesnoth/wesnoth/commit/971073055e2487560940790cc340d91cd8d8e8df now, but I will try next weekend.

Thanks

soliton- commented 1 week ago

Can you post the output of a run with --log-debug=filesystem?

doofus-01 commented 1 week ago

I was able to confirm that https://github.com/wesnoth/wesnoth/commit/971073055e2487560940790cc340d91cd8d8e8df does not work. Using --log-debug=filesystem with 81a1ef2 resulted in a flood that I forgot to save. For 9710730, it only gives 

Automatically found a possible data directory at: /home/USER/dev/wesnoth
info filesystem: Streaming /home/USER/dev/wesnoth/fonts/fonts.conf for reading.
debug filesystem: userdata using PREFERENCES_DIR '.wesnoth1_19'
error deprecation: --userdata-dir=<relative path> has been deprecated and will be removed in version 1.17.0.; Use absolute paths. Relative paths are deprecated because they are interpreted relative to $HOME
debug filesystem: userdata using PREFERENCES_DIR '.wesnoth1_19'
error deprecation: --userdata-dir=<relative path> has been deprecated and will be removed in version 1.17.0.; Use absolute paths. Relative paths are deprecated because they are interpreted relative to $HOME

where it hangs

Pentarctagon commented 1 week ago

It looks like it's the use of the PREFERENCES_DIR compile option that's somehow causing the issue - if I set that then I can reproduce this.

Pentarctagon commented 1 week ago

The issue is because the relative path for handling that option uses deprecated_message(). So while it's setting up the userdata directory it accesses the preferences which needs the userdata directory to already be setup (because how else would it know where the preferences are located?).

Pentarctagon commented 1 week ago

@doofus-01 for now, the workaround would be to set an absolute path for the PREFERENCES_DIR(cmake) or prefsdir(scons) build option rather than just the .wesnoth1_19 folder name.

soliton- commented 1 week ago

It's a bit unexpected that deprecated_message requires preferences access. Though this use of deprecated_message is presumably not really what it's for.

We should either not use deprecated_message for this or add a parameter to disable the preferences check which makes little sense here.

soliton- commented 1 week ago

I actually wondered why the issue does not reproduce when using --userdata-dir foo. Presumably that option is now broken since preferences are set up earlier. So then user_data_dir is set to one thing and preferences where read from elsewhere earlier.

So we have to be very careful now what triggers preferences initialization and userdata setup. Would be better if we move to some fixed startup behavior and error if something needs userdata/preferences earlier instead of something somewhere triggers userdata setup and something somewhere triggers preferences initialization.

Pentarctagon commented 1 week ago

Removing the functionality to make it be relative to $HOME instead of the current working directory (and thus the deprecated message) is #2000, so this would seem to be as good a time as any to remove that functionality. Additionally, this particular deprecation message likely never worked correctly in this scenario - the preferences causing the userdata to be initialized and the userdata initialization then needing the preferences would still have happened, it would have just silently used the default value for that preference rather than hanging.

I did attempt to add an assert to check for this sort of situation, however the problem ended up being that none of the tests (boost, WML, etc) actually setup the userdata before code somewhere in the tests attempted to access the preferences in some way: https://github.com/wesnoth/wesnoth/blob/77d023690a3b9f1f2e62a08615c619ac4a6f175e/src/preferences/preferences.hpp#L205-L211

I can make another attempt at getting that to function correctly though.

The place causing this issue is https://github.com/wesnoth/wesnoth/blob/77d023690a3b9f1f2e62a08615c619ac4a6f175e/src/game_launcher.cpp#L256 so presumably the command line options still work since they get parsed and the userdata location set prior to that point.

soliton- commented 1 week ago

The command line options work in that they set whatever when they are processed. That's not useful if what they should affect (like from where preferences are loaded) has already happened. Good if that is not what is happening now. (though there are many ways to run wesnoth...)

As long as code anywhere can unexpectedly trigger userdata setup and preference init there is potential for surprises though.

As you said the issue is not new. For preferences before the default was used which in this case even seems perfectly fine. Now getting stuck or loading preferences from the wrong place is a bigger potential issue.

doofus-01 commented 6 days ago

@Pentarctagon - Thank you for #9016. In case it matters, I just edit my .scons-option-cache, any compile option is no big deal, as long as it exists and is documented.

I didn't follow a lot of what you and @soliton- were saying here, but I think the only reason I got sucked into this is because I used version_suffix; I never explicitly specified a relative path.

version_suffix was a convenient way to have several independent versions of Wesnoth installed at once. Hopefully that continues to function, but I'll let you know.

Pentarctagon commented 6 days ago

Oh, huh. Currently the version_suffix option is ultimately providing a relative path even though it was previously deprecated and with #9016 that support will be removed, so I think that part of the version_suffix option probably needs to be removed as well, but once #9016 is merged you can accomplish the same thing by also adding prefsdir=~/.wesnoth as an option.