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 660965 - 100% CPU-load / segfault processing png-file
100% CPU-load / segfault processing png-file
Status: RESOLVED FIXED
Product: tracker
Classification: Core
Component: Extractor
0.12.x
Other Linux
: High critical
: ---
Assigned To: tracker-extractor
Jamie McCracken
: 672678 675933 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-10-05 08:20 UTC by Matthias Blümel
Modified: 2013-02-26 11:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
2 pictures, "Crystal.png" and "SomethingCross.png" (124.09 KB, application/zip)
2011-10-05 08:20 UTC, Matthias Blümel
  Details
Avoid a double-free in the png extractor (998 bytes, patch)
2013-02-26 04:54 UTC, Matthias Clasen
committed Details | Review

Description Matthias Blümel 2011-10-05 08:20:13 UTC
Created attachment 198310 [details]
2 pictures, "Crystal.png" and "SomethingCross.png"

while tracker made its initial index, tracker-extract used 100% of my cpu. I found out, that it was processing on the attached "Crystal.png" (part of the manslide 3d-slideshow-editor [1]). After killing the process it was immediately hanging on the next picture, "SomethingCross.png", until I killed it again.

/usr/libexec/tracker-extract -f ….png ends with an segmentation fault.

I am using tracker 0.12.3-r2 from the gnome-overlay for gentoo with USE="elibc_glibc exif firefox-bookmarks flac flickr gif gnome-keyring gstreamer gtk jpeg laptop mp3 nautilus networkmanager pdf playlist rss tiff vorbis xml -applet -doc -eds -gsf -iptc -test -thunderbird -upnp -xine -xmp"


[1] manslide: http://qt-apps.org/content/show.php/Manslide?content=55945
Comment 1 Alexandre Rostovtsev 2011-10-05 08:23:32 UTC
On my machine, running "/usr/libexec/tracker-extract -f Crystal.png" results in a segmentation fault. Here is the backtrace:

  • #0 malloc_consolidate
    at malloc.c line 5155
  • #1 malloc_consolidate
    at malloc.c line 5089
  • #2 _int_free
    at malloc.c line 5034
  • #3 __GI___libc_free
    at malloc.c line 3738
  • #4 png_read_destroy
    at pngread.c line 1282
  • #5 png_destroy_read_struct
    at pngread.c line 1212
  • #6 tracker_extract_get_metadata
    at tracker-extract-png.c line 910
  • #7 get_file_metadata
    at tracker-extract.c line 348
  • #8 tracker_extract_get_metadata_by_cmdline
    at tracker-extract.c line 798
  • #9 run_standalone
    at tracker-main.c line 304
  • #10 main
    at tracker-main.c line 392

Incidentally, this is with libpng-1.5.5.
Comment 2 Martyn Russell 2011-10-05 19:00:28 UTC
(In reply to comment #0)
> Created an attachment (id=198310) [details]
> 2 pictures, "Crystal.png" and "SomethingCross.png"
> 
> while tracker made its initial index, tracker-extract used 100% of my cpu. I
> found out, that it was processing on the attached "Crystal.png" (part of the
> manslide 3d-slideshow-editor [1]). After killing the process it was immediately
> hanging on the next picture, "SomethingCross.png", until I killed it again.
> 
> /usr/libexec/tracker-extract -f ….png ends with an segmentation fault.
> 
> I am using tracker 0.12.3-r2 from the gnome-overlay for gentoo with
> USE="elibc_glibc exif firefox-bookmarks flac flickr gif gnome-keyring gstreamer
> gtk jpeg laptop mp3 nautilus networkmanager pdf playlist rss tiff vorbis xml
> -applet -doc -eds -gsf -iptc -test -thunderbird -upnp -xine -xmp"
> 
> 
> [1] manslide: http://qt-apps.org/content/show.php/Manslide?content=55945

Hello Matthias, interesting you have 100% CPU. Is tracker configured to index only when idle on your machine? (in tracker-preferences)

Also, if you run the command yourself on the command line:

  /usr/libexec/tracker-extract -f $file

Does it do the same thing?

(In reply to comment #1)
> On my machine, running "/usr/libexec/tracker-extract -f Crystal.png" results in
> a segmentation fault. Here is the backtrace:

I don't get that here, but I am still using Natty. I am using 1.2.44-1ubuntu3.1. I will try on Oneiric beta tomorrow (which should have a newer version of libpng) to see if anything changes here.
Comment 3 Matthias Blümel 2011-10-14 16:55:16 UTC
(In reply to comment #2)
> Hello Matthias, interesting you have 100% CPU. Is tracker configured to index
> only when idle on your machine? (in tracker-preferences)

I changed the configuration a few times so I can't remember which setting it was when it was hanging

> Also, if you run the command yourself on the command line:
> 
>   /usr/libexec/tracker-extract -f $file

segfault

its also a segfault with the version 0.12.4 of tracker installed today


btw: I have installed libpng in Versions 1.2.46 and 1.4.8-r1. I don't know, which version tracker-extract is using. They were both installed before tracker.
Comment 4 Matthias Blümel 2011-10-15 15:25:41 UTC
same for 0.12.5
Comment 5 Martyn Russell 2012-04-30 15:30:58 UTC
*** Bug 672678 has been marked as a duplicate of this bug. ***
Comment 6 Martyn Russell 2012-08-23 20:40:14 UTC
*** Bug 675933 has been marked as a duplicate of this bug. ***
Comment 7 Martyn Russell 2012-08-23 20:43:50 UTC
Both bug 672678 and bug 675933 have good stack traces it's worth noting...
For now upgrading this bug report!
Comment 8 Matthias Clasen 2013-02-26 04:54:28 UTC
Created attachment 237407 [details] [review]
Avoid a double-free in the png extractor

The software member of the exif data was getting freed twice. So
whenever you deal with a png that has this field set to a non-NULL
value, you get a segfault.
Comment 9 Aleksander Morgado 2013-02-26 08:42:09 UTC
Review of attachment 237407 [details] [review]:

Looks good.
Comment 10 Matthias Clasen 2013-02-26 11:00:52 UTC
Attachment 237407 [details] pushed as 4306640 - Avoid a double-free in the png extractor
Comment 11 Matthias Clasen 2013-02-26 11:04:34 UTC
cherry picked to the tracker-0.14 branch as well
Comment 12 Martyn Russell 2013-02-26 11:14:23 UTC
Thanks Matthias, I will do a last (hopefully) release of 0.14.6 in the coming weeks and then start the 0.16.0 releases just as GNOME 3.8 comes out.