[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=378445

Nate Graham  changed:

   What|Removed |Added

 Status|NEEDSINFO   |RESOLVED
 CC||n...@kde.org

--- Comment #19 from Nate Graham  ---
Cool, thanks for following up!

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=378445

r...@alum.mit.edu changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME

--- Comment #18 from r...@alum.mit.edu ---
This has not happened to me in quite some time.  I'm fine with it being closed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[Justin Zobel]

https://bugs.kde.org/show_bug.cgi?id=378445

Justin Zobel  changed:

   What|Removed |Added

 Status|REPORTED|NEEDSINFO
 Resolution|--- |WAITINGFORINFO

--- Comment #17 from Justin Zobel  ---
Thank you for reporting this issue in KDE software. As it has been a while
since this issue was reported, can we please ask you to see if you can
reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when
replying. Thank you!

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=378445

--- Comment #16 from r...@alum.mit.edu ---
Happened again in charge_state_changed.

This *may* have been at the time my laptop reached full charge but I have no
logs.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=378445

--- Comment #15 from r...@alum.mit.edu ---
And another one, involving chargePercentChanged.  The laptop had been on AC for
an extended period of time prior, and was likely at 100% charged, but that
doesn't mean that ACPI can't report changes.

Installing all of the debuginfo packages is a pain, but would installing the
debuginfo for libKF5Solid alone be helpful?

#0  0x7ff626da413b in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x7ff626d2962a in malloc () from /lib64/libc.so.6
#2  0x7ff6270e7e38 in operator new(unsigned long) () from
/usr/lib64/libstdc++.so.6
#3  0x7ff62876765d in QQmlProperty::QQmlProperty(QObject*, QString const&)
() from /usr/lib64/libQt5Qml.so.5
#4  0x0040c65e in ?? ()
#5  
#6  0x7ff626d26634 in _int_free () from /lib64/libc.so.6
#7  0x7ff621144097 in QDBusUtil::isValidBusName(QString const&) () from
/usr/lib64/libQt5DBus.so.5
#8  0x7ff62111a721 in QDBusConnection::connect(QString const&, QString
const&, QString const&, QString const&, QStringList const&, QString const&,
QObject*, char const*) () from /usr/lib64/libQt5DBus.so.5
#9  0x7ff62111b013 in QDBusConnection::connect(QString const&, QString
const&, QString const&, QString const&, QObject*, char const*) () from
/usr/lib64/libQt5DBus.so.5
#10 0x7ff6135ee28a in ?? () from /usr/lib64/libKF5Solid.so.5
#11 0x7ff6135eac04 in ?? () from /usr/lib64/libKF5Solid.so.5
#12 0x7ff6135bf87e in
Solid::Device::listFromType(Solid::DeviceInterface::Type const&, QString
const&) () from /usr/lib64/libKF5Solid.so.5
#13 0x7ff5f83324b4 in ?? () from
/usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_powermanagement.so
#14 0x7ff5f8333255 in ?? () from
/usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_powermanagement.so
#15 0x7ff62766871c in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#16 0x7ff61361fc06 in Solid::Battery::chargePercentChanged(int, QString
const&) () from /usr/lib64/libKF5Solid.so.5
#17 0x7ff613622817 in ?? () from /usr/lib64/libKF5Solid.so.5
#18 0x7ff6276680d5 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#19 0x7ff61361f726 in ?? () from /usr/lib64/libKF5Solid.so.5
#20 0x7ff6135f0c5d in ?? () from /usr/lib64/libKF5Solid.so.5
#21 0x7ff613621a2d in ?? () from /usr/lib64/libKF5Solid.so.5
#22 0x7ff6276680d5 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#23 0x7ff613628ce3 in ?? () from /usr/lib64/libKF5Solid.so.5
#24 0x7ff62112549b in ?? () from /usr/lib64/libQt5DBus.so.5
#25 0x7ff627669886 in QObject::event(QEvent*) () from
/usr/lib64/libQt5Core.so.5
#26 0x7ff62764030c in QCoreApplication::notify(QObject*, QEvent*) () from
/usr/lib64/libQt5Core.so.5
#27 0x7ff627640245 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib64/libQt5Core.so.5
#28 0x7ff6276422a3 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib64/libQt5Core.so.5
#29 0x7ff62768f043 in ?? () from /usr/lib64/libQt5Core.so.5
#30 0x7ff623230134 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#31 0x7ff623230388 in ?? () from /usr/lib64/libglib-2.0.so.0
#32 0x7ff62323042c in g_main_context_iteration () from
/usr/lib64/libglib-2.0.so.0
#33 0x7ff62768e88c in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib64/libQt5Core.so.5
#34 0x7ff62763e6ab in
QEventLoop::exec(QFlags) () from
/usr/lib64/libQt5Core.so.5
#35 0x7ff627646344 in QCoreApplication::exec() () from
/usr/lib64/libQt5Core.so.5
#36 0x00409bf4 in ?? ()
#37 0x7ff626cce6e5 in __libc_start_main () from /lib64/libc.so.6
#38 0x00409e49 in _start ()

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=378445

--- Comment #14 from r...@alum.mit.edu ---
Happened again:

#0  0x7ff984e2d13b in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x7ff984db262a in malloc () from /lib64/libc.so.6
#2  0x7ff985170e38 in operator new(unsigned long) () from
/usr/lib64/libstdc++.so.6
#3  0x7ff9867f065d in QQmlProperty::QQmlProperty(QObject*, QString const&)
() from /usr/lib64/libQt5Qml.so.5
#4  0x0040c65e in ?? ()
#5  
#6  0x7ff984daf0b6 in _int_free () from /lib64/libc.so.6
#7  0x7ff984db1980 in _int_realloc () from /lib64/libc.so.6
#8  0x7ff984db2daf in realloc () from /lib64/libc.so.6
#9  0x7ff985590897 in QString::reallocData(unsigned int, bool) () from
/usr/lib64/libQt5Core.so.5
#10 0x7ff9855910d4 in QString::append(QString const&) () from
/usr/lib64/libQt5Core.so.5
#11 0x7ff97f1aa292 in ?? () from /usr/lib64/libQt5DBus.so.5
#12 0x7ff97f1ac253 in ?? () from /usr/lib64/libQt5DBus.so.5
#13 0x7ff97f1ac464 in ?? () from /usr/lib64/libQt5DBus.so.5
#14 0x7ff97f1a4013 in QDBusConnection::connect(QString const&, QString
const&, QString const&, QString const&, QObject*, char const*) () from
/usr/lib64/libQt5DBus.so.5
#15 0x7ff97582212b in ?? () from /usr/lib64/libKF5Solid.so.5
#16 0x7ff97581ec04 in ?? () from /usr/lib64/libKF5Solid.so.5
#17 0x7ff9757f387e in
Solid::Device::listFromType(Solid::DeviceInterface::Type const&, QString
const&) () from /usr/lib64/libKF5Solid.so.5
#18 0x7ff9513a24b4 in ?? () from
/usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_powermanagement.so
#19 0x7ff9513a3255 in ?? () from
/usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_powermanagement.so
#20 0x7ff9856f171c in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#21 0x7ff975853c06 in Solid::Battery::chargePercentChanged(int, QString
const&) () from /usr/lib64/libKF5Solid.so.5
#22 0x7ff975856817 in ?? () from /usr/lib64/libKF5Solid.so.5
#23 0x7ff9856f10d5 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#24 0x7ff975853726 in ?? () from /usr/lib64/libKF5Solid.so.5
#25 0x7ff975824c5d in ?? () from /usr/lib64/libKF5Solid.so.5
#26 0x7ff975855a2d in ?? () from /usr/lib64/libKF5Solid.so.5
#27 0x7ff9856f10d5 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#28 0x7ff97585cce3 in ?? () from /usr/lib64/libKF5Solid.so.5
#29 0x7ff97f1ae49b in ?? () from /usr/lib64/libQt5DBus.so.5
#30 0x7ff9856f2886 in QObject::event(QEvent*) () from
/usr/lib64/libQt5Core.so.5
#31 0x7ff9856c930c in QCoreApplication::notify(QObject*, QEvent*) () from
/usr/lib64/libQt5Core.so.5
#32 0x7ff9856c9245 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib64/libQt5Core.so.5
#33 0x7ff9856cb2a3 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib64/libQt5Core.so.5
#34 0x7ff985718043 in ?? () from /usr/lib64/libQt5Core.so.5
#35 0x7ff9812b9134 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#36 0x7ff9812b9388 in ?? () from /usr/lib64/libglib-2.0.so.0
#37 0x7ff9812b942c in g_main_context_iteration () from
/usr/lib64/libglib-2.0.so.0
#38 0x7ff98571788c in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib64/libQt5Core.so.5
#39 0x7ff9856c76ab in
QEventLoop::exec(QFlags) () from
/usr/lib64/libQt5Core.so.5
#40 0x7ff9856cf344 in QCoreApplication::exec() () from
/usr/lib64/libQt5Core.so.5
#41 0x00409bf4 in ?? ()
#42 0x7ff984d576e5 in __libc_start_main () from /lib64/libc.so.6
#43 0x00409e49 in _start ()

Again, I don't know this code, but there are some commonalities about the stack
traces:

1) They're always in a signal handler that's invoking
QQmlProperty::QQmlProperty, allocating memory.

2) Above the signal handler, they're allocating or freeing memory (not really
all that surprising; most versions of malloc aren't re-entrant).

3) Above that there are a variety of things, but they all seem to happen from
Solid::Battery::chargePercentChanged or Solid::Battery::chargeStateChanged.

In this case -- it hasn't always been true -- I had just driven home from work
with the laptop suspended, so the battery would have run down a bit.  I had
plugged it back in, resumed it, checked email, and then shut the lid (locking
the screen, but not suspending the laptop).  The hang happened about 10 minutes
after I first resumed it, so it's certainly possible that the laptop's charge
percent might have changed.  In other cases, though, it happened overnight,
when the laptop was surely fully charged.  That doesn't guarantee that the
charge state isn't changing, though.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=378445

--- Comment #13 from r...@alum.mit.edu ---
That's not likely what happened here; this most often happens overnight when I
had shut the laptop's lid, and it's not right after I shut it either (I have my
lid set to lock when shut, not suspend).

I wasn't able to induce this behavior.  The problem is that the lock sequence
must consist of at least two keys (main key and modifier), and as soon as one
of the keys is touched during the grace period, the screen unlocks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=378445

--- Comment #12 from Martin Gräßlin  ---
Assuming the signal handler is the reason the steps to reproduce are:
Let screen lock through idle timeout and during grace period lock the screen
through shortcut

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=378445

--- Comment #11 from Martin Gräßlin  ---
In the case of sigusr1 it could happen that memory gets allocated from the
signal handler.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[bugzilla_noreply]

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.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=378445

--- Comment #9 from Martin Gräßlin  ---
or another explanation could be memory corruption or even defect RAM.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[David Edmundson]

https://bugs.kde.org/show_bug.cgi?id=378445

David Edmundson  changed:

   What|Removed |Added

 CC||k...@davidedmundson.co.uk

--- Comment #8 from David Edmundson  ---
How on Earth do we get from:


#7  0x7f4f607cd097 in QDBusUtil::isValidBusName(QString const&) () from
/usr/lib64/libQt5DBus.so.5

to 

#4  0x0040c65e in ScreenLocker::UnlockApp::setLockedPropertyOnViews
(this=) at
/usr/src/debug/kscreenlocker-5.9.4/greeter/greeterapp.cpp:414


isValidBusName is just a string check making sure it's "foo.bar.blah" It can't
call or emit anything, no nested event loops or anything.


The ony thing this means is that we have a corrupt backtrace.

This could be beause the debug symboles were installed badly and refer to a
different version - or we have some code smashing the stack. 

Also note that the two backtraces are actually different. The first is in
QDBusServiceWatcher::QDBusServiceWatcher, which the second isn't in.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[bugzilla_noreply]

https://bugs.kde.org/show_bug.cgi?id=378445

--- Comment #7 from r...@alum.mit.edu ---
Still happens with kscreenlocker (and powerdevil) 5.9.4.

It's rare, so I can't reproduce it reliably.  And I don't have the debuginfo
packages -- my normal source for KDE packages doesn't have the debuginfo
packages so I have to go back to download.opensuse.org and download them
specially for doing this.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 378445] kscreenlocker_greet occasionally freezes in malloc in signal handler

[Martin Gräßlin]

https://bugs.kde.org/show_bug.cgi?id=378445

Martin Gräßlin  changed:

   What|Removed |Added

 Status|NEEDSINFO   |UNCONFIRMED
 Resolution|FIXED   |---
Product|kscreenlocker   |Powerdevil
  Component|greeter |general
   Assignee|plasma-b...@kde.org |plasma-de...@kde.org

--- Comment #6 from Martin Gräßlin  ---
reassigning to powerdevil as it seems to be inside upower dbus handling

-- 
You are receiving this mail because:
You are watching all bug changes.