https://bugs.kde.org/show_bug.cgi?id=378445
--- Comment #10 from r...@alum.mit.edu --- Note that frame 5 is a signal handler, so it's hardly surprising that frame 4 and frame 7 are unrelated. I don't know this code, but it sure looks to me like something (in the second trace, isValidBusName; in the first case, probably something different but I didn't have debug symbols installed) was in the middle of free'ing something, during which time kscreenlocker_greet() received a signal, and the signal handler did a new QQmlProperty while the memory allocator was locked by the free() called synchronously above it, so we have a deadlock. My own guess -- and obviously this isn't my code -- is that something in kscreenlocker_greet has set a signal handler (possibly a timeout) that is allocating memory -- a no-no, unless you're using a re-entrant version of malloc. I'm pretty certain I had the right -debuginfo packages installed; rpm does the version checking quite well. And I don't think it's bad memory either; the problem is consistently within the signal handler within kscreenlocker_greet, and I don't see any other indications of bad memory on the system. -- You are receiving this mail because: You are watching all bug changes.
