| Summary: | KWin crashes randomly | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Ilya V. Portnov <portnov> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | crash | CC: | halla |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.2.2 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Ilya V. Portnov
2015-06-20 16:16:50 UTC
The crash is in QtScript, I assume because var newProfile = profiles[client.resourceClass]; You could protect it var newProfile; if (client.resourceClass in profiles) newProfile = profiles[client.resourceClass]; I don't know enough about ECMA to say whether accessing an undefined hash key should throw an exception, but you're right that QtScript should not crash. Unfortunately I could not find a Qt bug report, so you may want to file one. Hello. I tried to put try ... catch around all body of onFocus function. It did not help. For some reason, kwin crashes every time I close window with "yes/no/cancel" question about saving data from Krita. These steps always lead to kwin crash in my case: * Open Krita * Create new document * Draw any stroke * Press close button on Krita window. It will ask, if you want to save document. * Answer No * Dialog box and Krita window closes, and kwin crashes. @Boud: any idea whether Krita does something "special" in the steps described in comment #2? Same backtrace? Did you isolate your script? (ie. if it's perfectly reproducible, is it reproducible w/o your script as well?) @Martin something special I could think of would be that two closing windows rapidly get focus (modal dialog -> closes -> main client -> closes) It will be krita because krita is handled by the script. The second client.resourceClass call could resolve to a dying/invalidated object and cause a memory corruption. no, nothing special, though krita is a qtsingleapplication. The problem seems to have something to do with script: if I remove the script, the problem does not reproduce. Can you please try
var className = client.resourceClass;
withTabletProfile(function(tablet, oldProfile) {
var newProfile = profiles[className];
...
I frankly cannot read the ECMA functor syntax, nor knows how it will act, but it looks a lot like some async dbus stuff is invoked what *may* result in async or threaded execution of your main slot - and the client object being gone in the meantime.
You also may (no idea whether that'd be an improvement) want to include a timer here and check the workspace.activeClient class on timeout to update the wacom stuff.
var updateDelay = new QTimer;
updateDelay.singleShot = true;
updateDelay.timeout.connect(onFocus); // TODO: function names should indicate what the function does, not what may or may not trigger it :-P
workspace.clientActivated.connect(function(){updateDelay.start(250);}); // <- I hope i counted the braces correctly ;-)
PS: dbus is rather "slow" I/O - so you may - unrelated to this bug - want to cache the last active resourceClass and skip action if either it didn't change or old and new are not in the profile map (ie. you stay with the default profile) |