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

[bugzilla_noreply at kde.org]

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

--- Comment #14 from rlk at alum.mit.edu ---
Happened again:

#0  0x00007ff984e2d13b in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00007ff984db262a in malloc () from /lib64/libc.so.6
#2  0x00007ff985170e38 in operator new(unsigned long) () from
/usr/lib64/libstdc++.so.6
#3  0x00007ff9867f065d in QQmlProperty::QQmlProperty(QObject*, QString const&)
() from /usr/lib64/libQt5Qml.so.5
#4  0x000000000040c65e in ?? ()
#5  <signal handler called>
#6  0x00007ff984daf0b6 in _int_free () from /lib64/libc.so.6
#7  0x00007ff984db1980 in _int_realloc () from /lib64/libc.so.6
#8  0x00007ff984db2daf in realloc () from /lib64/libc.so.6
#9  0x00007ff985590897 in QString::reallocData(unsigned int, bool) () from
/usr/lib64/libQt5Core.so.5
#10 0x00007ff9855910d4 in QString::append(QString const&) () from
/usr/lib64/libQt5Core.so.5
#11 0x00007ff97f1aa292 in ?? () from /usr/lib64/libQt5DBus.so.5
#12 0x00007ff97f1ac253 in ?? () from /usr/lib64/libQt5DBus.so.5
#13 0x00007ff97f1ac464 in ?? () from /usr/lib64/libQt5DBus.so.5
#14 0x00007ff97f1a4013 in QDBusConnection::connect(QString const&, QString
const&, QString const&, QString const&, QObject*, char const*) () from
/usr/lib64/libQt5DBus.so.5
#15 0x00007ff97582212b in ?? () from /usr/lib64/libKF5Solid.so.5
#16 0x00007ff97581ec04 in ?? () from /usr/lib64/libKF5Solid.so.5
#17 0x00007ff9757f387e in
Solid::Device::listFromType(Solid::DeviceInterface::Type const&, QString
const&) () from /usr/lib64/libKF5Solid.so.5
#18 0x00007ff9513a24b4 in ?? () from
/usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_powermanagement.so
#19 0x00007ff9513a3255 in ?? () from
/usr/lib64/qt5/plugins/plasma/dataengine/plasma_engine_powermanagement.so
#20 0x00007ff9856f171c in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#21 0x00007ff975853c06 in Solid::Battery::chargePercentChanged(int, QString
const&) () from /usr/lib64/libKF5Solid.so.5
#22 0x00007ff975856817 in ?? () from /usr/lib64/libKF5Solid.so.5
#23 0x00007ff9856f10d5 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#24 0x00007ff975853726 in ?? () from /usr/lib64/libKF5Solid.so.5
#25 0x00007ff975824c5d in ?? () from /usr/lib64/libKF5Solid.so.5
#26 0x00007ff975855a2d in ?? () from /usr/lib64/libKF5Solid.so.5
#27 0x00007ff9856f10d5 in QMetaObject::activate(QObject*, int, int, void**) ()
from /usr/lib64/libQt5Core.so.5
#28 0x00007ff97585cce3 in ?? () from /usr/lib64/libKF5Solid.so.5
#29 0x00007ff97f1ae49b in ?? () from /usr/lib64/libQt5DBus.so.5
#30 0x00007ff9856f2886 in QObject::event(QEvent*) () from
/usr/lib64/libQt5Core.so.5
#31 0x00007ff9856c930c in QCoreApplication::notify(QObject*, QEvent*) () from
/usr/lib64/libQt5Core.so.5
#32 0x00007ff9856c9245 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() from /usr/lib64/libQt5Core.so.5
#33 0x00007ff9856cb2a3 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () from /usr/lib64/libQt5Core.so.5
#34 0x00007ff985718043 in ?? () from /usr/lib64/libQt5Core.so.5
#35 0x00007ff9812b9134 in g_main_context_dispatch () from
/usr/lib64/libglib-2.0.so.0
#36 0x00007ff9812b9388 in ?? () from /usr/lib64/libglib-2.0.so.0
#37 0x00007ff9812b942c in g_main_context_iteration () from
/usr/lib64/libglib-2.0.so.0
#38 0x00007ff98571788c in
QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
from /usr/lib64/libQt5Core.so.5
#39 0x00007ff9856c76ab in
QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from
/usr/lib64/libQt5Core.so.5
#40 0x00007ff9856cf344 in QCoreApplication::exec() () from
/usr/lib64/libQt5Core.so.5
#41 0x0000000000409bf4 in ?? ()
#42 0x00007ff984d576e5 in __libc_start_main () from /lib64/libc.so.6
#43 0x0000000000409e49 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 the assignee for the bug.