tracker-extract causes system lock-up due to 100% CPU and memory usage

Hi,

I originally reported this problem on the Ubuntu tracker-miners package, but the package maintainer asked me to file upstream. Launchpad bug is here: https://bugs.launchpad.net/ubuntu/+source/tracker-miners/+bug/1826439

Immediately after upgrading from Ubuntu 18.10 to 19.04, my computer froze about 30-40 secs after I logged in.

I finally tracked this down to the tracker-extract process. This process starts within about half a minute after logging in. When it starts, there's a matter of seconds until the process consumes 100% CPU and all available system memory (I have 16 GB on an Intel 8700k @ 4.8 GHz and SSD/M.2).

This only happens with my regular user. It does not occur with a newly created user (I guess due to the large amount of files within my home directory).

It happens every time I log in.

This phenomenon causes the entire system to freeze up completely. The wheels seem to fall off the wagon in such a way the system can't recover. The only alternative at this point is a hard reset or SysRQ REISUB. It is not possible to switch to a TTY (ctrl-alt-fX), and it's not possible to ssh in from another machine. SysRQ-k does not work. I've tried logging in to a TTY before logging in to the GUI, and then switching to the TTY quickly after logging in to the GUI. Surely enough - a few seconds later the TTY locks up as well.

I can reproduce the problem easily, but I'm not sure how to go about debugging it - would be happy to assist. I can't let the process run for more than a few seconds at a time so bear that in mind. I tried grabbing the process in gdb, but the package seem to be stripped of debug symbols. I did a strace -p for a few seconds and the process appears to be symlinking files in my homedirectory to a subdirectory within /tmp (?!?) - I can get more details here if it helps.

A bonus question from me is how it's possible that a process run by a user can take down the entire system in this manner.

tracker-extract and tracker-miner-fs: 2.1.6-1 tracker: 2.1.8-2 kernel: 5.0.0-13-generic (I've also tried 5.0.9)

I've attached a photo(!) of top illustrating what's going on (at this point the machine has already frozen up. There appears to still be some memory available, but this is just because top never got around to report the true numbers before the machine died.)