GNOME Bugzilla – Bug 620182
Indexing stalls with tracker-store using 100% CPU
Last modified: 2010-06-01 13:56:05 UTC
During indexing of my home directory using tracker 0.9.5, always at 17%, i have tracker-store using 100% CPU and indexing won't progress from there on, or at least not for a fairly long while (I have waited some five minutes). A backtrace from tracker-store: (gdb) thread apply all bt
+ Trace 222174
Thread 2 (Thread 0xb7653b70 (LWP 4907))
I can see in the tracker-store log that the file it chokes on is an ascii file of about 1MB full of numbers (the result of some number crunching program of mine). I can attach logs upon request, but they don't seem to contain anything of interest.
Could you possibly attach that given ASCII file in the bug report?
Created attachment 162436 [details] Example of ASCII file triggering the bug This is the file on which it hung last time. I'm not positive it always hangs on the very same one, but i've observed it hang in the same directory (which has various of those data files) at least three times.
Hi Alexander, It seems the glib/pango parser doesn't perform very well if the file only contains numbers. It took, as you say, around 5 minutes to parse the whole contents of the 1MByte file using the glib/pango parser. In the other hand, if using libunistring or libicu based parsers with the same file, the results are pretty different: 0.023s for libunistring parser and 0.053s for libicu. I would suggest to use either libunistring or libicu parsers instead of glib/pango one (using the --with-unicode-support=[libunistring|libicu] configure option. If available, libunistring performs generally better than the libicu parser. Cheers.
Turns out this is a problem with the glib/pango text extraction module. the libunistring based one performs much better, and that is also given preference if it is available. packagers should therefore ensure it is used if the system provides it.