Unfortunately, no... I have been refraining for posting updates, because I'm engaging in some major stupidity with ltrace right now, since it seem that as of now, only reverting works. While I was doing some testing, I decided to try X session of plasma, and results are the same there. The only difference is, on wayland everything screen related is frozen, but on X the mouse cursor is still responsive.
One difference wrt the thread you posted, downgrading pixman solved it for the guy, but not for me. I only got a working config after downgrading SDL2_image also, hence the name of the thread. I would test with SDL2_image only, but doing magic key SIGTERM and then logging in just to reboot(I don't know if firewall dies also, so, a precaution if you will) is a major annoyance.
Yesterday, I played around with Kwin debugging under wayland, adding a line in ~/.bash_profile:
Code:
export QT_LOGGING_RULES="kwin_*.debug=true"
The results being, at hang time, the log has two repeating lines:
Code:
kwin_core: KWin::XwaylandWindow(0x23cf310, windowId=0x4600005, surface=KWaylandServer::SurfaceInterface(0x24b8f50), caption="Launcher") true false false
kwin_core: PERMITTED KWin::XwaylandWindow(0x23cf310, windowId=0x4600005, surface=KWaylandServer::SurfaceInterface(0x24b8f50), caption="Launcher") true
I also ran Proton with PROTON_LOG=1, result at hang being:
Code:
969.919:0138:0148:trace:seh:NtGetContextThread 0xfffffffe: eax=000000de ebx=00000001 ecx=00000000 edx=00000000 esi=00000001 edi=0320f8e0
969.919:0138:0148:trace:seh:NtGetContextThread 0xfffffffe: ebp=0320f9f8 esp=0320f89c eip=7bc0c55c cs=0023 ss=002b flags=00000246
969.919:0138:0148:trace:seh:NtGetContextThread 0xfffffffe: ds=002b es=002b fs=0063 gs=006b
which repeats Ad-Infinitum until SIGTERM. That look like 32 bit processor registers(64 bit is rax?) and flags to me, and looking up seh, that may be a microsoft exception handling thingy, but I'm new at this, so who knows. Which seems to me like Proton and Kwin are caught in a loop - I'd expect them to just fail and be done with it. I haven't bothered to see if I can log CPU utilization, to see if they just hog one core, while the other 3 keep the kernel alive.
I did find descriptions of problems with 535 nvidia driver
here, related
here, and a description very similar to mine
here, although it seems X11 specific. None of the described solutions worked in the wayland session.
So, as any reasonable person would do, knowing nothing about debugging in general, least of all on linux, I decided to look up some profiling and debugging tools. I'm not smart enough for ptrace, strace is for system calls, but ltrace was promising, since I have a known suspect library, that while it may not be the actual culprit, just makes the failure 100% reliable. I was always hoping to learn how to use GDB also, for my own purposes when dabbling in programming, but that plan was on hold for a while - need to get this system set up to my liking first.
SlackBuilds has a nice script for patching and building ltrace, so I modified that to my purposes. But, using the naive way to try to attach a trace to steam itself, and then follow the children to Proton was... well, naive... By itself, it crashes nicely... It is possible to run it against steam as described
here on Arch wiki, even tho they don't mention ltrace in supported list. That kinda runs, but eventually fails after initial version check.
So that was kinda bad. Then I read up on the actual internal proton tooling, and if you use the Experimental beta with debug symbols, you can set the debug flag:
Code:
PROTON_DUMP_DEBUG_COMMANDS=1
which will write some nice shell scripts to set up the environment for winedbg --gdb to /tmp/proton-username. That started the .exe in debug mode, but, like I said, I haven't learned GDB yet, and, it seemed to me like it was tracking just the exe, and not the actual wine calls themselves? Got no useful output, but I did get a regular hang with the Launcher interface coming up and freezing.
So, doing another sensible thing, I modified the generated script by removing winedbg --gdb, and just kept the last shell magic that runs the actual .exe... I mean, what's the worst thing that could happen, I fork bomb myself?
Of course, ltrace was not happy, since a shell script is not an ELF... but of course, bash is, and if you trace it and it's children while executing the script...
In other words, I'm sitting on some 863KiB of plain text log that I need to grep, from startup until launcher screen hang
I wasn't going to post anything until I got a result, or if I failed due to lack of knowledge, I could just let the thread die quietly and pretend it didn't happen. But since you're following this issue and it seems there's some strange things going on elsewhere, figured might as well update you all on what I've been up to. If nothing else, someone that does this for a living might find it amusing
