Lutris 0.5.14 sometimes crashes when accessing Settings > Global options #5092
Comments
|
Hmm. Did this happen in 0.5.13? I notice it refers to libpango, and we've started using Pango- to write the 'Missing' badge on the media for games whose directory is missing. Try this: Go into Preferences and activate the option to "Hide badges on icons"; then restart Lutris. Now, go into settings and try those options again. Does it still crash? |
|
It still crashes sometimes when that option is checked. |
|
Hmm, so much for that theory. If it's not that little badge, I'm not sure what's happened in 0.5.14 that's affecting you. It's GTK that's blowing up, I think. Maybe it's related to KDE somehow? I'm just guessing at this point. |
|
I can confirm. OS: EndeavourOS Linux x86_64 |
|
Seems like maybe KDE Plasma is the common factor here. |
|
The system tab is making calls to various tools like xrandr and vulkan-info so that's probably what's crashing Lutris on some KDE setups. |
|
Lutris with --debug:
Dmesg shows this:
EDIT:
|
|
Looks like the xrandr calls are getting through so it's probably vulkan-info that is causing the issue, or more precisely, how python retrieves the output of vulkan-info and loads it in the UI |
|
I'm immediately suspicious of the vkquery stuff. If the C API declarations are wrong... |
|
This is happening for me as well. Running System Info: |
|
I consistently get segfaults/coredumps when going to "System Options" of a game as well: $ lutris
2023-11-03 00:21:59,153: Command 'fluidsynth' not found on your system
2023-11-03 00:21:59,625: Starting Lutris 0.5.14
2023-11-03 00:21:59,628: Using NVIDIA drivers 535.113.01 for x86_64
2023-11-03 00:21:59,628: GPU: NVIDIA GeForce GTX 960M
2023-11-03 00:21:59,628: GPU: 8086:191B 17AA:3802 (i915 drivers)
2023-11-03 00:21:59,628: GPU: 10DE:139B 17AA:3802 (nvidia drivers)
Segmentation fault (core dumped)$ lutris
2023-11-03 00:22:18,321: Command 'fluidsynth' not found on your system
2023-11-03 00:22:18,804: Starting Lutris 0.5.14
2023-11-03 00:22:18,807: Using NVIDIA drivers 535.113.01 for x86_64
2023-11-03 00:22:18,807: GPU: NVIDIA GeForce GTX 960M
2023-11-03 00:22:18,807: GPU: 8086:191B 17AA:3802 (i915 drivers)
2023-11-03 00:22:18,807: GPU: 10DE:139B 17AA:3802 (nvidia drivers)
corrupted size vs. prev_size
Aborted (core dumped)$ lutris --debug
2023-11-03 00:30:07,333: Command 'fluidsynth' not found on your system
INFO 2023-11-03 00:30:07,822 [application.do_command_line:436]:Starting Lutris 0.5.14
INFO 2023-11-03 00:30:07,824 [startup.get_drivers:57]:Using NVIDIA drivers 535.113.01 for x86_64
INFO 2023-11-03 00:30:07,825 [startup.get_drivers:61]:GPU: NVIDIA GeForce GTX 960M
INFO 2023-11-03 00:30:07,825 [display.display_gpu_info:78]:GPU: 8086:191B 17AA:3802 (i915 drivers)
INFO 2023-11-03 00:30:07,825 [display.display_gpu_info:78]:GPU: 10DE:139B 17AA:3802 (nvidia drivers)
DEBUG 2023-11-03 00:30:08,300 [xrandr._get_vidmodes:16]:Retrieving video modes from XrandR
DEBUG 2023-11-03 00:30:09,407 [lutris.get_missing_game_ids:202]:Checking for missing games
DEBUG 2023-11-03 00:30:15,064 [application.show_window:359]:Showing window EditGameConfigDialog1
DEBUG 2023-11-03 00:30:17,727 [xrandr._get_vidmodes:16]:Retrieving video modes from XrandR
DEBUG 2023-11-03 00:30:18,002 [xrandr._get_vidmodes:16]:Retrieving video modes from XrandR
DEBUG 2023-11-03 00:30:18,118 [xrandr._get_vidmodes:16]:Retrieving video modes from XrandR
DEBUG 2023-11-03 00:30:18,178 [xrandr._get_vidmodes:16]:Retrieving video modes from XrandR
DEBUG 2023-11-03 00:30:18,247 [xrandr._get_vidmodes:16]:Retrieving video modes from XrandR
DEBUG 2023-11-03 00:30:28,467 [game.save:429]:Saving The Iron Oath (wine) with config ID the-iron-oath-1698958502
DEBUG 2023-11-03 00:30:28,467 [config.save:227]:Saving LutrisConfig(level=game, game_config_id=the-iron-oath-1698958502, runner=wine) config to /home/falk/.config/lutris/games/the-iron-oath-1698958502.yml
DEBUG 2023-11-03 00:30:29,756 [lutris.add_to_path_cache:160]:Adding The Iron Oath (wine) to path cache
DEBUG 2023-11-03 00:30:29,775 [application.on_app_window_destroyed:377]:Removed window EditGameConfigDialog1
DEBUG 2023-11-03 00:30:33,903 [application.show_window:359]:Showing window EditGameConfigDialog1
malloc(): unaligned tcache chunk detected
Aborted (core dumped)$ inxi -F
System:
Host: aska Kernel: 6.5.9-arch2-1 arch: x86_64 bits: 64 Desktop: KDE Plasma
v: 5.27.9 Distro: Arch Linux
Machine:
Type: Laptop System: LENOVO product: 80NV v: Lenovo ideapad Y700-15ISK
serial: <superuser required>
Mobo: LENOVO model: Allsparks 5A v: SDK0J40709 WIN
serial: <superuser required> UEFI: LENOVO v: CDCN54WW date: 06/13/2017
Battery:
ID-1: BAT0 charge: 43.8 Wh (100.0%) condition: 43.8/60.0 Wh (73.0%)
CPU:
Info: quad core model: Intel Core i5-6300HQ bits: 64 type: MCP cache:
L2: 1024 KiB
Speed (MHz): avg: 800 min/max: 800/3200 cores: 1: 800 2: 800 3: 800 4: 800
Graphics:
Device-1: Intel HD Graphics 530 driver: i915 v: kernel
Device-2: NVIDIA GM107M [GeForce GTX 960M] driver: nvidia v: 535.113.01
Device-3: Intel RealSense 3D Camera (Front F200) driver: uvcvideo
type: USB
Display: x11 server: X.Org v: 21.1.9 with: Xwayland v: 23.2.2 driver: X:
loaded: modesetting,nvidia dri: iris gpu: i915 resolution: 1: 2560x1440~60Hz
2: N/A
API: EGL v: 1.5 drivers: nvidia platforms: gbm
API: OpenGL v: 4.6.0 vendor: nvidia v: 535.113.01 renderer: NVIDIA
GeForce GTX 960M/PCIe/SSE2
API: Vulkan v: 1.3.269 drivers: nvidia surfaces: xcb,xlib
Audio:
Device-1: Intel 100 Series/C230 Series Family HD Audio driver: snd_hda_intel
API: ALSA v: k6.5.9-arch2-1 status: kernel-api
Server-1: PipeWire v: 0.3.83 status: active
Network:
Device-1: Intel Dual Band Wireless-AC 3165 Plus Bluetooth driver: iwlwifi
IF: wlp8s0 state: up mac: 84:ef:18:ad:a4:58
Device-2: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
driver: r8169
IF: enp9s0 state: down mac: c8:5b:76:5e:63:af
IF-ID-1: nordlynx state: unknown speed: N/A duplex: N/A mac: N/A
Bluetooth:
Device-1: N/A driver: btusb type: USB
Report: btmgmt ID: hci0 state: up address: 84:EF:18:AD:A4:5C bt-v: 4.2
Drives:
Local Storage: total: 4.51 TiB used: 2.72 TiB (60.3%)
ID-1: /dev/nvme0n1 vendor: Corsair model: Force MP510 size: 894.25 GiB
ID-2: /dev/sda vendor: Seagate model: BUP BK size: 3.64 TiB type: USB
Partition:
ID-1: / size: 863.1 GiB used: 192.12 GiB (22.3%) fs: ext4
dev: /dev/nvme0n1p3
ID-2: /boot size: 299.4 MiB used: 107.5 MiB (35.9%) fs: vfat
dev: /dev/nvme0n1p1
Swap:
ID-1: swap-1 type: partition size: 16 GiB used: 0 KiB (0.0%)
dev: /dev/nvme0n1p2
Sensors:
System Temperatures: cpu: 55.0 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Processes: 208 Uptime: 2h 36m Memory: total: 16 GiB available: 15.45 GiB
used: 5.49 GiB (35.6%) Shell: fish inxi: 3.3.30Hybrid GPU laptop, but I do |
|
Ok, this affects me as well. This bug is really annoying. It never happened for me in 0.5.13, and now it happens almost every time I go into system options. |
|
if only any of the people affected was able to do a bisect. |
|
I believe I'm seeing it in a Fedora 39 KDE Plasma VM. But it's not reliable at all; seems to crash sometimes if you start Lutris from the panel, go to preferences, and just click among the views for a bit. But more often, no crash. If I can get a repo out of this VM, I can bisect this. But it's so ghosty right now. So far, I've seen no crashes when I start from the command line, though it's the same Lutris 0.5.14 from the repo.
Never mind, I've seen it crash from the command line too. Seems to happen more if I go directly to Global Options and don't visit anything else first. |
|
Well, it's too ghosty to bisect but I tried NOP-ing out the vkquery.py stuff, and it still crashes. So it's not just a messed up declaration in there, at least. |
|
Bisecting led me to this commit 259c4f4 |
|
so it's likely in one of the subprocess calls. A crash in vkquery.py would likely produce a better python stacktrace. |
that sort of makes sense. That code doesn't even respect the utility functions we have to call subprocess and looks very flimsy. |
|
I also have this issue, but i found a different commit, so i assume its because of a different reason? Starts stuttering (~3s) at 2bd8806 I havent tested with a clean config yet. System Information [CPU] [Memory] [Graphics] Log from 2bd8806 Log from 9acc43b Couldnt get it to crash, so killed it instead. Log from 0.5.14 with slow start: |
|
OK, I've NOPped out the get_locale_list() code and that does seem to avert the crash. But I also tried to replace the call to Popen with our own system.execute() and that did not help a bit. I do not understand what's causing us to crash here. I tried switching to locale.locale_alias.values() to get the list, and that crashes, but seems to crash less often. |
|
I think I see it; it's not how we get the locales, it's how big it is. This i a drop down with 873 locales in it on my VM; I think that's triggering a GTK bug of some kind here. I'll put together a branch that limits the drop down to the UTF-8 options, which are "(recommended)", and you'd have to type in any other locale. Might be an acceptable solution if it works. |
It's still a long list, but all locales seemed to be caused crashes. You can always type in some other locale, if UTF-8 is not your thing. Resolves #5092
|
OK, branch is ready. If you are having this crash, please download this branch here, and the run the bin/lutris script inside. With this branch, the Locale dropdown will list only UTF-8 locales if you have any, which is still a lot really. You'll have to type in your own locale if you want EBCDIC, sorry. But I hope this will avoid the crashes people have been having. |
|
That dropdown has to go and needs to be replaced with a text field. |
|
I think that's just a revert away- it was a text field before, if I recall. But if we could provide a reasonable - and short - set of options here that'd be better than a text field. My branch isn't that, though. Still, I hope interested parties will still test it, see if I'm onto something here. If so, I expect a text field would fix the issue as well or better. |
|
From what I understand, the locale option (which I've never used) is useful for Japanese or Russian games. That said, MAME has a dropdown for the machine option and that has over 4000 entries. I've never had anyone complain about it crashing. |
Still crashes for me on that branch.
I don't think the number of locales is the problem here, since I only have 7 locales on my system and It's crashing. |
|
@madscientist16 can you try replacing all occurrences of |
|
Well, nobody wants to retest this now, so I'll pop a PR to be merged if you like the new drop-down. I hope it will fix the crash too. |
|
Even without further testing, this is much more user friendly. Now, anyone has any theories on why this would only happen on KDE? |
Clearly, KDE sees how GNOMEy we've become and Does Not Approve. |
|
Hi, sorry for the late reply. I can confirm Lutris doesn't crash with that branch. |
|
OK, I'll take 'yes' for an answer and merge this PR myself. |
|
Been getting these segfaults as well and using the lutris script from master did not fix the issue |
|
Not sure what's causing this, but I've going through and made sure we've got function signatures on every single C API we use- some were missing. Could have caused memory corruption. I'd ask you, @skeezmoe, to get the very latest master and see if that has helped at all. |
|
Even the drop-down hamburger menu can cause Lutris to crash randomly when opened. This is pretty bad. I've never had issues like this in 0.5.13. This has to be some kind of bad commit somewhere in the 0.5.14 release that's causing these issues. pretty buggy release. |
|
It's been quite solid for me, but @strycore been seeing crashes and has tried to bisect it; the latest master has been more stable for him since he reverted a seemingly innocuous commit. These crashes sound like memory corruption to me, and I've been hunting for something that could cause that. I've tried to beef up the libvulkan integration just hours before your comment. If you haven't tried the very, very latest @Liverel, I think you should. Download the latest code (don't try to install it) and run the 'bin/lutris' script therein; perhaps we've made some progress on this. A thread-safety issue in our GTK usage is possible, but I've turned up nothing like that so far. That would be triggered by doing some particular thing in Lutris, but we did just change the startup UI... I wish we could see a clearer pattern here; could people with this issue post the 'Hardware Information'? Maybe there's a pattern. Like, are you all on KDE? That was the pattern for this issue originally, and I was able to get somewhere with that... |
|
Maybe I should be more suspicious of the new startup stuff. It downloads runtime updates in the background, which only happens occasionally so it can't just be the actual update itself causing so many crashes. But there's a fancy new UI to show progress in the sidebar and there are threads involved too. Sooo... Here's a branch with all that cut out; it can't update at all and the new UI is no longer present in the main window. If anybody is still having the crashes, please download this butchered branch and let us know if it is better. It'll be a big clue if it is, though we can't ship something like this. |
|
I have this exact issue now and I'm happy to help test solutions. I've allowed Lutris to open and remain idle, no crash. I've went through each and every menu item, no crash. It's not until I open Preferences -> Global Options, does it crash. Sometimes instantly, others momentarily after. But it seems that the trigger is certainly opening this menu (and only opening it, it doesn't even need to be interacted with). After trying a few times to open it repeatedly (restarting the application and accessing the menu), it seems to work without issue. The same issue occurs when accessing an individual games properties via Configure -> System Options. Let me know what else I can provide or offer to help with a solution. |
|
If you are running version 0.5.14 of lutris, try downloading this repo and running the 'bin/lutris' script to see if it still crashes. |
|
@s3gfault, let us know if the latest master helps. If it does not, please try my hacked branch which removes some code I'm suspicious of. Let us know! |
|
I'm on Arch using the Plasma desktop and using lutris-git from the AUR. It's less crashy in the git version than the stable release, but it can still crash out of nowhere. Also, one thing to note is that ever since 0.5.14, the configure window takes a little bit longer to open than on 0.5.13 before it opened instantly. Now it takes a little longer. Also, on Wayland, hovering the mouse while that window opens now that it takes several miliseconds to open causes Lutris to crash, but this crash only gets triggered when my mouse is set to 1000Hz. This seems very similar to the 1000Hz mouse crash that Firefox gets when running in Wayland as well. I've never gotten this type of crash because of my mouse before on earlier Lutris releases under Wayland thou. |
|
I've noticed the similarity to the 1000 Hz mouse issue. It may be that we're reacting too slowly and causing the the pipe to back up if a lot of mouse input is incoming; I don't have this problem, but my mouse isn't so fancy. I don't know why the config dialog is slower to open, but now that you point it out, I see it too. I shall bisect it. |
|
OK, the slowdown appears to be the integration of flatpak based runners; I'll try to optimize this. However,for now I've made another hacked branch that cuts that out, right here. @Liverel, or other people who are suffering crashes, please download that branch and run the 'bin/lutris' script there in. Is that any less crashy? Faster at least? |
The dialog opens instantly on that branch, and moving around the mouse while it opens doesn't cause the crash anymore. |
|
Excellent. I've added just a bit of cache in the master branch that keeps flatpak working but much more cheaply (but it won't notice you installing a new runner in flatpak until you restart Lutris). Please try the latest master; is it also improved now? And let us know if you are still getting other crashes. |
|
I just updated the aur lutris-git. The dialog opens instantly, and the mouse doesn't crash it anymore there either. Nice |
|
Very good. I fear there will be crashes elsewhere in Lutris; @strycore reports that the branch did not help him at all. But one step at a time! |
|
Since that seemed to help @Liverel, I've got a new branch that goes further, and tries to avoid spawning helper processes during install as well. If you having been having crashes in the install-window, give it a try and let us know. Still shooting in the dark really, but maybe, just maybe... |
|
The crashs I've been having were caused by having to many events stacking up in the GUI thread. On wayland and with a high DPI mouse, it was easy to resolve. Any operation that can lock up the UI should be done in a background task. From doing HTTP requests to reading/writing to HDD drives (sometimes HDD drives go to sleep and it takes a couple seconds for them to spin up again) Deporting the code making HTTP requests in a thread separate from the main Gtk thread has solved all known crashes on Wayland. If anyone is aware of crashes that still happen on the latest code, please let me know! Lutris will just exit and say |
@danieljohnson2 To finish the conversation. Yes, the crashes seem to have vanished completely. I said mitigated because even before they just happend every thirtiest time or so and I didn't want to open the context menu for a hundred times just to be sure. 😄 Edit: For statistics |
Bug description
Lutris 0.5.14 sometimes crashes when accessing Settings > Global options in Fedora 38 KDE (wayland session). It also sometimes happens when accessing "System options" section of a Runner's options.
dmesg shows this:
lutris[2046611] general protection fault ip:7f0b2e59ad33 sp:7f0b090baf60 error:0 in libglib-2.0.so.0.7600.5[7f0b2e53a000+a0000]
lutris[3245093] general protection fault ip:7f6b3702f260 sp:7f6b12abad50 error:0 in libpango-1.0.so.0.5000.14[7f6b3700e000+39000]
I am sometimes shown this in lutris output:
Gtk:ERROR:../gtk/gtkcssinheritvalue.c:33:gtk_css_value_inherit_free: code should not be reached
**
Gtk:ERROR:../gtk/gtkcssinheritvalue.c:33:gtk_css_value_inherit_free: code should not be reached
Bail out! Gtk:ERROR:../gtk/gtkcssinheritvalue.c:33:gtk_css_value_inherit_free: code should not be reached
Bail out! Gtk:ERROR:../gtk/gtkcssinheritvalue.c:33:gtk_css_value_inherit_free: code should not be reached
fish: Job 1, '/usr/bin/lutris' terminated by signal SIGABRT (Abort)
How to Reproduce
Steps to reproduce the behavior:
Expected behavior
Not crash when accessing certain settings pages
Log output
System Information
Media (optional)
No response
Checklist:
The text was updated successfully, but these errors were encountered: