Where does 0.49 store crash logs on linux ?

[LoneWolf]

About half an hour ago my system crashed hard (black screen, nothing responded) while playing openmw.
I waited some minutes to allow for the creation of a crash log before pressing the powerbuttton to force a shutdown.

System logs (snippet at bottom) show the issue is gpu/driver related. I searched for crash logs in ~/.config/openmw where they've always been but couldn't find any this time.
openmw wiki and openmw readthedocs don't mention crash logs at all.

Is there a different location I should look at ?

Code: Select all

Aug 22 15:42:35 silverbolt kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=1719502, emitted seq=1719504
Aug 22 15:42:35 silverbolt kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process openmw pid 16711 thread openmw:cs0 pid 16
713
Aug 22 15:42:35 silverbolt kernel: amdgpu 0000:42:00.0: amdgpu: GPU reset begin!

[psi29a]

There will likely be no logs, this is a driver / kernel bug. You might find something in your Xorg log. Please file a bug report with Xorg Mesa's bug tracker for amdgpu.

[LoneWolf]

Nothing in xorg log, and I have no idea what caused the crash so can't reproduce it.
I will consider filing a mesa bug and posting on archlinux forum.

Which leaves the question "where does openmw store crash logs on linux ?" open .

https://gitlab.com/OpenMW/openmw/-/comm ... 1d4b61dccb appears to have changed the location for crash logs .

Code: Select all

#else
            const std::string crashLogName = Misc::StringUtils::lowerCase(appName) + "-crash.log";
            // install the crash handler as soon as possible.
            crashCatcherInstall(
                argc, argv, Files::pathToUnicodeString(std::filesystem::temp_directory_path() / crashLogName));
#endif

That leads to https://en.cppreference.com/w/cpp/files ... ctory_path .

I'm almost certain openmw follows the xdg base directory spec on linux. , so that points to XDG_RUNTIME_DIR .
On my system that is default set to /run/user/1000 . Unfortunately /run is a tmpfs and anything on it is lost on shutdown/poweroff .

Even if openmw had produced a crash log, it would not be available after shutdown.

Should I consider setting TMPDIR before starting openmw to ensure crash logs won't disappear ?

[Chris]

https://gitlab.com/OpenMW/openmw/-/comm ... 1d4b61dccb appears to have changed the location for crash logs .

Code: Select all

#else
            const std::string crashLogName = Misc::StringUtils::lowerCase(appName) + "-crash.log";
            // install the crash handler as soon as possible.
            crashCatcherInstall(
                argc, argv, Files::pathToUnicodeString(std::filesystem::temp_directory_path() / crashLogName));
#endif

That leads to https://en.cppreference.com/w/cpp/files ... ctory_path .

That doesn't look like a good place at all. "directory location suitable for temporary files". I wouldn't consider logs and crash logs to be temporary files, they should persist at least until the next run of the game (or the user explicitly deletes them). "Temporary files" to me means files that stick around for the run of the app, but are prone to deletion any time after the process ends, which isn't good for logs you want to ensure access to afterward.

[AnyOldName3]

They were moved from the normal log directory to the temp directory as:

• When not using a portable install, it's likely OpenMW will be in a write-restricted directory, so we can't put crash logs/dumps into the install directory.

• When using a portable install, we don't want to put crash logs/dumps into the default logs directory as that isn't what we're using for other logs.

• We might crash long before we've figured out which log directory we're going to end up using, so can't defer picking the location.

For Windows, the temp directory's default location is a pain to get at, especially for inexperienced users, as it's buried in AppData, which is a hidden directory. As the crash dump path was stored in a shared memory object which only gets read from when a crash actually happens, and there was already a mechanism for locking it, it was fairly easy for me to change it so we'd change the crash dump directory to the regular log directory once we figured out what it was going to be, and only use temp before we'd done that. None of the same code is involved with the Unix crash catcher, though, so it was unaffected, and I didn't want to go poking around in code I didn't understand right before a release, so as it was a less critical concern, I left the Unix implementation as-is.

[LoneWolf]

Understood, I checked the xdg base directory spec furether and found a recent (2 years ago) addition that looks like a good candidate to store logs : XDG_STATE_HOME .

From https://specifications.freedesktop.org/ ... atest.html

There is a single base directory relative to which user-specific state data should be written. This directory is defined by the environment variable $XDG_STATE_HOME.

A bit further down on that page there's more detail :

$XDG_STATE_HOME defines the base directory relative to which user-specific state files should be stored. If $XDG_STATE_HOME is either not set or empty, a default equal to $HOME/.local/state should be used.

The $XDG_STATE_HOME contains state data that should persist between (application) restarts, but that is not important or portable enough to the user that it should be stored in $XDG_DATA_HOME. It may contain:

actions history (logs, history, recently used files, …)

current state of the application that can be reused on a restart (view, layout, open files, undo history, …)