GNOME Bugzilla – Bug 761670
jpegdec: Possible endless loop if file is corrupt
Last modified: 2016-04-14 17:42:39 UTC
Created attachment 320572 [details] the jpeg file triggering this Today I noticed tracker-extract using 100% for hours on a JPG file I had on my disk. The (attached) file is actually a corrupt file I received some time ago from a bug report in eog. It's part of a suite of image files that were created using some new data fuzzing tool: http://lcamtuf.coredump.cx/afl/demo/ When tracker-extract started working on it, it's JPEG extraction module failed, however it then falls back to its GStreamer module where it starts using 100% CPU. Turns out it's easy to reproduce with GStreamer alone: gst-launch-1.0 filesrc location=<filename> ! jpegdec ! autovideosink Debugging it, it looks like gst_jpeg_dec_fill_input_buffer is passing the file data over and over again into the decoder instead of reporting EOF/EOS. The decoder isn't noticing the problem as it is waiting for a SOF or a EOI JPEG marker (both are missing in the file) and thus is looping endlessly over the same image data.
I confirm the bug. As this element does not stream the jpeg to the decoder (it sends complete frames), it make no sense to do anything in _fill callback. I'm not saying it shouldn't stream (this would use slightly less memory, and could reduce the latency), but it's the state of it.
Created attachment 320584 [details] [review] jpegdec: Don't pass the same data over and over We already pass the entire frame to the decoder. If the decoder ask for more data, don't pass the same data again as this leads to infinit loop. Instead, simply fail the fill function to signal the problem with that frame. It will then be skipped properly.
Attachment 320584 [details] pushed as 905e28a - jpegdec: Don't pass the same data over and over
This is probably a candidate for backport.