Skip to content

Draft: Reduce the memory footprint of signond

jpalecek requested to merge jpalecek/signond:master into master

Hi!

While testing the gdrive integration for kde, I noticed similar problems as described in #15, namely, that signond was consuming gigabytes of memory. Also, sometimes (often after a computer resume) it just blew up and triggered OOM Killer. I thought this was due to a single bug, but it ended up being two.

I ran signond under valgrind, connected to it using vgdb and with the monitor leak_check command, discovered that there are tens of thousands of SignonAuthSessionAdaptor instances and friends. It seems like they are continuously created, but never deleted. It kind-of makes sense, because they aren't SignonDisposables, but rather wait for their governing SignonSessionCore to delete them when it itself is deleted. However, in the case of kio-gdrive, this almost never happens, since it continuously generates requests belonging to the same SignonSessionCore. This problem is also alluded to in issue #2.

So this MR changes that so a single SignonAuthSession is also a DisposableObject and can be reclaimed individually regardless of its parent SignonSessionCore.

However, this didn't exactly fix all the problems, because the triggering of the OOM Killer remained. It turned out that's caused by an (not really, but almost) infinite recursion involving SignonDisposable::destroyUnused. It calls SignonSessionCore::destroy which deletes all its children which in turn calls SignonDisposable::destroyUnused (here). And because SignonDisposable doesn't remove the same SignonSessionCore from its lists until after calling ->destroy(), this cycle repeats several times and can lead to stack overflow.

Merge request reports