This is a normal KDE task netinstall of stretch on a Thinkpad X220
(clean install, not an upgrade).  I'm going to keep my laptop in
suspect until Monday, when I need to use it for work again.  Until
then I will only resume from S3 to help debug the dbus-daemon and kde5
memory leak bugs.  After Monday, I am afraid that the opportunity to
track this down again will be lost for a while.

I've attached relevant ps -aux and top output, and the gdb session.
The relevant -dbg.* packages have been installed to produce a
meaningful bt.  No package seems to provide pthread_cond_wait.S ...

  Using host libthread_db library
  "/lib/x86_64-linux-gnu/libthread_db.so.1".
  pthread_cond_wait@@GLIBC_2.3.2 ()
      at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
  185     ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No
  such file or directory.
  #0  pthread_cond_wait@@GLIBC_2.3.2 ()
      at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185

Please let me know what else I can do to help track this down.

Raising severity because 6520.81MB is enough to make the OOM killer
kill a browser on a laptop with less than 8GB of RAM, when the user is
running without swap (possibly also with zswap) because he/she is
using an SSD, or to make the system swap so hard that it becomes
unusable.  Please see #879898 for Simon McVittie's analysis about how
this issue also causes the user's session's dbus-daemon memory to also
balloon.

Please let me know what I can do to help debug this further, because
I'd like to help solve this asap.  This time I triggered the issue on
my desktop.  Please note that while my desktop is running a custom
kernel, my laptop is running linux-4.9 shipped in Debian Stretch.  I'm
sticking with 4.4 on my Desktop, because linux-4.9 has a couple of
btrfs regressions that haven't yet been patched...I don't take risks
with my primary system.

Relevant output from top:
19242 sten      20   0 6916852 5.320g    956 S   0.0 36.5   6:12.07 kded5
 2673 sten      20   0 2029908 1.584g    264 S   0.0 10.9   4:38.57 dbus-daemon

Full backtrace is attached, created with:
file /usr/bin/kded5
thread apply all backtrace no-filters full


Sincerely,
Nicholas

kded acts as a proxy to the background kde services, most likely the leak is
in one of them, not in kded per se. I'm degrading the severity as I can't
reproduce it.

¡Hola Nicholas!

El 2017-11-29 a las 05:14 -0500, Nicholas D Steeves escribió:

It would be helpful to know which threads kded is executing, in order to do
that please run the following command: pstree -tp | less, and look for the kded
processes.

Also it would be interesting to know which services are being managed by kded,
to find that out you can use the system settings' "Startup and Shutdown"
"Background services", you can see which services are currently running in you
session, you can attach your ~/.config/kded5rc that stores this information.

A known culprit on wasting resources is the baloo file indexer (which should
be disabled by default), I don't remember seeing a leak in kded related to
baloo, but I haven't paid much attention to it since we disabled it. You can
check if your file indexer is disabled in: "System Settings" "Search" "File
Search" "Enable File Search"

Happy hacking,