After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 754365 - tracker-extract uses a lot or virtual memory
tracker-extract uses a lot or virtual memory
Status: RESOLVED DUPLICATE of bug 737663
Product: tracker
Classification: Core
Component: Extractor
unspecified
Other Linux
: Normal normal
: ---
Assigned To: tracker-extractor
tracker-extractor
Depends on:
Blocks:
 
 
Reported: 2015-08-31 16:17 UTC by Xavier Claessens
Modified: 2015-09-01 20:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Xavier Claessens 2015-08-31 16:17:14 UTC
I am running tracker on an 64bits device with 2G of RAM. tracker-extract abort() because malloc() returns NULL while extracting media files. The problem is not that it reached out of memory, but reached the limit of 960M of VIRTUAL memory it sets itself using setrlimit(). If I stop the process in gdb when it aborts, "top" says it's using 962832K of VIRT but only 33288K of RES.

On my ubuntu 15.04 amd64 laptop, "top" says tracker-extract uses 509728K of VIRT and 6648K of RES. This is a lot for a process doing nothing.

Note that the problem is not wasting RAM since it's only virtual memory that the kernel won't count (top still say I have plenty of free memory) but that tracker-extract can easily reach the limit it sets with setrlimit() and then abort.

With pmap <pid>, I see for example 7 mapped blocks like this one:
00007f2550022000  65400K -----   [ anon ]

Note that itc ould be a bug in a library tracker uses for extracting media metadata, like GStreamer.
Comment 1 Xavier Claessens 2015-08-31 16:17:45 UTC
Oh, and I can't seems to be able to reproduce this bug in i386 VM.
Comment 2 Xavier Claessens 2015-08-31 18:20:35 UTC
This is an old bug actually. Looks like the root cause was never found, but there is no limit anymore in tracker 1.4+

*** This bug has been marked as a duplicate of bug 737663 ***
Comment 3 Martyn Russell 2015-09-01 20:17:50 UTC
(In reply to Xavier Claessens from comment #2)
> This is an old bug actually. Looks like the root cause was never found, but
> there is no limit anymore in tracker 1.4+
> 
> *** This bug has been marked as a duplicate of bug 737663 ***

Yea, we removed teh limit, it was causing too many false positives.