[Bug] OpenBVE freezes at the loading screen #1050
Comments
|
OK, that's interesting.... I've only got a pretty elderly Intel integrated graphics (HD3000), which normally is Windows / Hackintosh only. Looking into the code, the default timeout for texture loading is 1000ms in the main game ( https://github.com/leezer3/OpenBVE/blob/master/source/OpenBVE/System/GameWindow.cs#L1180 ; you're linking to the Route Viewer method. I'm not sure off the top of my head why there's no timeout here, possibly an oversight) I'd suspect there's probably a strong element of machine / disk based timing in this as well. I'll see what I can do about reproducing with that. |
|
Good, that reproduces on the VM with mesa_glthread=true set. Going to do a little excavating.... |
|
OK, I think we had a livelock problem there. I think more people haven't reported this simply due to the fact that timing here was absolutely critical. @ginga81 The build from today will hopefully resolve your freeze when not running under WINE. (I could probably just set this environment variable process wide, but I'd quite like to actually fix the issue rather than mask it) |
|
If I understand the fix correctly, I think that it does not eliminate the deadlock, it just reduces the likelihood of it. It might this might be fixed by just removing the |
|
However, I wouldn't rule out that we are seeing two different bugs. The bug that I was seeing could be distinguished by that the |
|
I have tested the commit 71689f6 on the Intel machine and the game is still getting stuck when I use The deadlock seems to be reliable (the game never successfully loads with the |
|
What I've changed is an issue with queues. It's a little complex, but basically, if we add an item to a queue from one thread (length > 0), but at the same time are returning the pulse signal from another, one of the two can be silently discarded, despite the fact a lock was in use. This then leaves the loop stuck waiting for a return. It's a pity that this doesn't solve it for you. Let me think on it a bit. |
|
I finally got the Mono SDB debugger running on the Intel machine. Here are the C# stacktraces when the deadlock happens: Output of "thread bt" in Mono sdb debugger when the deadlock happens |
I've missed this, I agree that this could also be causing problems on the loading screen. |
|
I immediately tried the daily build, but unfortunately it was at 0%. |
|
Have you tried setting the environment variable mentioned in the first message? If not, please try the build which will generate in a few minutes, which will automatically set this variable. For what it's worth, after looking into the OpenTK code, I can't see this being anything other than a MESA bug. |
|
Sorry for not setting the environment variables. |
|
I'm now swayed towards this being a Mesa bug as well. I can reproduce this on the generic Zink OpenGL-on-Vulkan driver ( |
|
Only thing I do wonder is if OpenTK is mis-handling a failing call somewhere, as nested locking within a thread is absolutely possible with X. If it hasn't called to release the lock exactly the same number of times as it took it, then this might actually be expected. (if IMHO atrocious design on the part of X) I'll try and see about looking into that, but OpenTK build isn't liking the main Windows machine at the minute.... |
|
I have now tested the latest nightly OpenBVE build on the AMD machine (where the |
|
I have reproduced the Mesa deadlock using a tiny C app and I have created a Mesa bugreport for that - https://gitlab.freedesktop.org/mesa/mesa/-/issues/11558. |
Description
On some Linux OpenGL drivers, OpenBVE will freeze during the "Loading track" screen. The CPU is just idle in that state.
Reproduction
mesa_glthread=truepart is not even necessary. This is because Mesa enabled its OpenGL threaded dispatch in new releases by default: https://www.phoronix.com/news/Mesa-22.3-RadeonSI-glthread-OnCause
I have debugged this and it turns out that OpenTK deadlocks the Mesa driver. The game freezes because the
SwapBuffers()call never returns:OpenBVE/source/OpenBVE/System/GameWindow.cs
Line 1125 in 2539167
The cause is that OpenTK calls
XLockDisplay()before callingGlx.SwapBuffers()(link). The Mesa driver in glthread mode also wants to acquire the lock. The situation can be described like this:XLockDisplay()Glx.SwapBuffers()XLockDisplay()equivalent likely to be able to access the X11 socketI have found opentk/opentk#691 and that looks somewhat similar, but that applies only to other GLX calls.
When the glthread mode is disabled, I assume that this deadlock will not happen because the GL commands will be processed from within the OpenBVE thread.
Workarounds
mesa_glthread=falseenvironment variable. This switches the Mesa driver into a mode where this bug does not happen./usr/share/drirc.d/01-openbve.confwith the following contents:DRI configuration file contents
preferNativeBackendOpenBVE option in~/.config/OpenBve/Settings/1.5.0/options.cfgtofalse. This makes OpenTK use SDL2 for SwapBuffers and SDL2 does not have this issue.Related issues
It seems to me that #944 might be the same issue.
Route
Any route is likely sufficient, but http://md.archive.ubuntu.com/ubuntu/ubuntu/pool/universe/b/bve-route-cross-city-south/bve-route-cross-city-south_1.31.08-0ubuntu2_all.deb was used.
Train
Any train is likely sufficient , but https://packages.ubuntu.com/jammy/bve-train-br-class-323 was used.
Logs
These are from the Intel machine. If needed, I can also provide logs from the AMD machine, but these logs were fairly similar.
OpenBVE log.txt
GDB stacktrace of the Mesa GL thread when the deadlock happens
GDB stacktrace of the OpenBVE renderer thread when the deadlock happens
If needed, I can also post the full C#/Mono backtrace. However, I remember the following:
OpenBVE/source/OpenBVE/System/GameWindow.cs
Line 1125 in 2539167
OpenBVE/source/RouteViewer/System/Gamewindow.cs
Line 208 in 2539167
Related information
The text was updated successfully, but these errors were encountered: