tracker-extract seems to briefly consume 1.5GB memory and slow computer right down

I am also affected from a similar behaviour.
I notice this behaviour of tracker-extract reproducibly after login (into the gnome desktop).
If I react quickly after the windows are setup and start directly a terminal with top sorted by memory consum, I notice that it is tracker-extract who is the "top scorer", that means. on my machine it consumes all of my memory. mouse pointer does not move, system monitor in panel does not refresh. This lasts some time and when tracker-extract terminates, the situation calms down. after some 3 minutes same behaviour. when this has passed I can work normally with the system. as I already mentioned: reproducible behavior after every login.

I use Ubuntu (10.10/maverick, beta, updated today 05.10.10) 64bit.

oh. I forgot to mention: all of my memory means 2 GB RAM (+10% of 2 GB swap)

Status changed to 'Confirmed' because the bug affects multiple users.

I'm using Ubuntu GNOME 14.10 and I found this problem too. tracker-extract takes 1.5 GB of memory and slow down, including change to another window using Alt+Tab, taking lot of seconds to response.

Same thing here. Ubuntu Gnome 14.10 64 bit on an Asus P301LA notebook with 4 GB RAM.
After login in gnome shell the system is very unresponsive for many minutes. After a while, usually, tracker-miner crashes and the systems goes back to normal behaviour.
Apport says: tracker-extract crashed with SIGABRT in g_malloc0().

So, there are a few things mentioned here, let me answer them:

1. Any case where you see SIGABRT is usually Tracker killing itself due to seriously high memory use. This has been removed for 1.3.x onwards. What this means is, instead of getting a SIGABRT and the process closing, your machine will be brought to its knees if there are broken 3rd party implementations OR files not following standards. This is usually the reason for SIGABRT, it's rarely a Tracker bug.

2. The tracker-extract process has recently had a fail-safe added to it, so if extraction attempts fail more than 'n' times, we will stop trying. This avoids the "login, fail, login, fail, etc" cycle.

3. If you're seeing high memory use, please file a bug upstream with the file(s) causing this and we will try to fix it. The same with slow down. Some people have crazy PDF content (for example) which can take a LOOONG time to extract and use GBs of memory. This is not Tracker's fault.

Finally, I want to add that the reason we have a tracker-extract process is EXACTLY because 3rd party content or libraries are not reliable enough and often deviate from standards. The process is built with crashing expected at some point, and we do try our best NOT to let this happen - but it's not always in our control.

Thanks,

I ran into > 1 GB memory that caused swapping (due to useful programs using most memory) with the below version in Ubuntu 14.04. It's lasted for several minutes so far (total CPU time 30 minutes).

The idea that this is not a bug is ludicrous. It must be able to handle running into bad content – by ignoring it if necessary – and not balloon to such high memory use.

ii tracker-extract 0.16.5-0ubuntu0.1 amd64 metadata database, indexer and search tool - metadata extractors

I just scanned 30 documents with Simple Scan in 600 dpi and saved them as png and got 2.1 gigabytes memory usage for tracker-extract (Ubuntu Gnome 15.10). The memory was never deallocated. Simple Scan is missing some usability features: it doesn't tell when it is actually processing the image; you have to wait several seconds for the "Saving image" notification to pop up. I don't know what the trigger case/root cause is or what Simple Scan is doing (however, I know I'm not going to try reproducing the scanning...).

Let's see... I actually scanned 41 files, totaling 1.5 GB. And saw the memory usage steadily growing as I scanned.