https://bugs.kde.org/show_bug.cgi?id=387232
--- Comment #3 from RJVB <rjvber...@gmail.com> --- Oops, crossed comments. Yes, the only immediate explanation I can see is that a "watchDir" signal was delivered to my lambda after a project was unloaded (the lambda that's now connected without explicit connection type specifier, you know what I mean). What I don't understand is how this can have happened; the signal source should also have been taken down when the project was being unloaded. It may have been related to overall instability which also caused the CPU burning. I've been running this code for weeks now and never saw this happen before. I'm making some changes - disconnecting the "watchDir" signal explicitly in the appropriate locations and catching QCoreApplication::aboutToQuit in ProjectWatcher to stop the monitoring. That seems like a reasonable thing to do anyway. Is there anything else one can do to prevent queued signals that get delivered after the target was deleted, handle them properly? Maybe use deleteLater() on the watcher instance? -- You are receiving this mail because: You are watching all bug changes.
