https://bugs.winehq.org/show_bug.cgi?id=57220
Bug ID: 57220 Summary: FL Studio - ENTIRE SYSTEM CRASH WHEN SCROLLING Product: Wine Version: 9.17 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: agarplayerarlon@gmail.com Distribution: ---
Created attachment 77133 --> https://bugs.winehq.org/attachment.cgi?id=77133 Video of the issue & system crash
In the video I've attached you can see 1 issue where the mouse pointer isn't stuck on the parameter I'm scrolling, and the 2nd is that the video ends when the system crashed, and of course it shouldn't crash, this happens on all desktop envirorments and on all Wine versions.
How to reproduce the issue: Install FL Studio free version https://www.image-line.com/fl-studio-download/ You'll encounter bug 57208 "https://bugs.winehq.org/show_bug.cgi?id=57208" that I've reported, the program will eventually install but it will take 30 minutes at least After it's installed try to scroll the BPM value as I did in the video by pressing the left click on it and moving the mouse up and down
Expected behaviour: When scrolling the BPM parameter, the mouse pointer disappears and gets stuck in the point where you left click, and reappears in the same point where you stop holding the left click And the system doesen't crash
https://bugs.winehq.org/show_bug.cgi?id=57220
--- Comment #1 from Miliardo agarplayerarlon@gmail.com --- Created attachment 77134 --> https://bugs.winehq.org/attachment.cgi?id=77134 Same video in different format as the mp4 doesen't seem to load on the browser
https://bugs.winehq.org/show_bug.cgi?id=57220
Miliardo agarplayerarlon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|FL Studio - ENTIRE SYSTEM |FL Studio - Entire system |CRASH WHEN SCROLLING |crash when scrolling
https://bugs.winehq.org/show_bug.cgi?id=57220
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal
--- Comment #2 from Austin English austinenglish@gmail.com --- A system crash is indicative of a kernel bug or (video) driver bug. You should file a bug with your distribution.
Check dmesg/journalctl for what went wrong.
https://bugs.winehq.org/show_bug.cgi?id=57220
--- Comment #3 from Miliardo agarplayerarlon@gmail.com --- (In reply to Austin English from comment #2)
A system crash is indicative of a kernel bug or (video) driver bug. You should file a bug with your distribution.
Check dmesg/journalctl for what went wrong.
thanks for the reply
this happens in all distributions, in all wine version and both on nvidia and amd, and both on x11 and wayland, that's why I think the bug is related with Wine
https://bugs.winehq.org/show_bug.cgi?id=57220
--- Comment #4 from Austin English austinenglish@gmail.com --- (In reply to Miliardo from comment #3)
(In reply to Austin English from comment #2)
A system crash is indicative of a kernel bug or (video) driver bug. You should file a bug with your distribution.
Check dmesg/journalctl for what went wrong.
thanks for the reply
this happens in all distributions, in all wine version and both on nvidia and amd, and both on x11 and wayland, that's why I think the bug is related with Wine
Wine may be _triggering_ the bug, but if the kernel is crashing, the bug is in the kernel. The kernel shouldn't crash because of something Wine is doing.
https://bugs.winehq.org/show_bug.cgi?id=57220
--- Comment #5 from Miliardo agarplayerarlon@gmail.com --- (In reply to Austin English from comment #4)
Thank you for the reply!
From my understanding it's a bug that happens in Wine that then triggers the system to crash, as you can see from the attachment when I try to change the BPM value on the top left of the screen, by pressing left click on the bpm value and moving the mouse up and down, the mouse pointer is still able to move freely, while the expected behavior is for the mouse to stay locked and not move, and that will then trigger the crash after some seconds.
So if we fix that bug that doesen't lock the mouse pointer into position, the system crash will not happen
https://bugs.winehq.org/show_bug.cgi?id=57220
--- Comment #6 from Miliardo agarplayerarlon@gmail.com --- (In reply to Austin English from comment #4)
this is what the logs are saying when the system crashes:
23:32:48 FL64.exe: X connection to :0 broken (explicit kill or server shutdown). 23:32:37 systemd: dbus-:1.2-org.gnome.Nautilus@1.service: Consumed 5.936s CPU time, 94.8M memory peak. 23:32:37 nautilus: GSConnect: [Errno 2] No translation file found for domain: 'org.gnome.Shell.Extensions.GSConnect' 23:32:36 FL64.exe: 01f8:fixme:explorerframe:taskbar_list_SetProgressState iface 00000000012D1400, hwnd 0000000000020142, flags 2 stub! 23:32:36 gnome-shell: Window manager warning: Window 0x1a0000f (FL Studio) sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense. 23:32:36 FL64.exe: 01f8:fixme:dwmapi:DwmEnableMMCSS (-1) stub 23:32:35 gnome-shell: g_source_remove: assertion 'tag > 0' failed 23:32:35 wireplumber: m-lua-scripting: Got invalid index when switching profile 23:32:35 gnome-shell: g_source_remove: assertion 'tag > 0' failed 23:32:35 pipewire-pulse: mod.protocol-pulse: 81: source not ready: sample:0 map:0 volume:0 23:32:35 FL64.exe: 01f8:fixme:powrprof:PowerGetActiveScheme (0000000000000000,000000000011DA78) stub! 23:32:35 gnome-shell: Window manager warning: Invalid WM_TRANSIENT_FOR window 0x1a00008 specified for 0x1c00006 (). 23:32:34 FL64.exe: 01f8:fixme:uxtheme:BufferedPaintInit Stub () 23:32:32 kernel: x86/split lock detection: #AC: FL64.exe/10344 took a split_lock trap at address: 0x140159f21
https://bugs.winehq.org/show_bug.cgi?id=57220
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dark.shadow4@web.de
--- Comment #7 from Fabian Maurer dark.shadow4@web.de --- I can confirm the mouse cursor not being stuck in place (didn't test against windows though), but no crash here.