GNOME Bugzilla – Bug 778090
PNG extractor decompresses images in memory
Last modified: 2017-03-08 10:41:32 UTC
Created attachment 344798 [details] htop screenshot tracker-extract process DDOS my system (gdb) thread apply all bt
+ Trace 237104
Thread 28 (Thread 0x7f7c7e169700 (LWP 12217))
Thread 27 (Thread 0x7f7c813ab700 (LWP 12158))
Thread 26 (Thread 0x7f7c82ffd700 (LWP 12155))
Thread 25 (Thread 0x7f7c83fff700 (LWP 12137))
Thread 24 (Thread 0x7f7cb10e3700 (LWP 12134))
Thread 23 (Thread 0x7f7cb290c700 (LWP 12133))
Thread 22 (Thread 0x7f7cb3737700 (LWP 12132))
Thread 21 (Thread 0x7f7cd2140700 (LWP 12131))
Thread 20 (Thread 0x7f7cb18e4700 (LWP 12115))
Thread 19 (Thread 0x7f7cb20e5700 (LWP 12100))
Thread 18 (Thread 0x7f7cb673d700 (LWP 12099))
Thread 17 (Thread 0x7f7cb5f3c700 (LWP 12098))
Thread 16 (Thread 0x7f7cd3fff700 (LWP 12054))
Thread 15 (Thread 0x7f7ce1ffb700 (LWP 12053))
Thread 14 (Thread 0x7f7ce2ffd700 (LWP 12046))
Thread 13 (Thread 0x7f7ce37fe700 (LWP 12045))
Thread 12 (Thread 0x7f7ce3fff700 (LWP 12044))
Thread 11 (Thread 0x7f7ce8ff9700 (LWP 12043))
Thread 10 (Thread 0x7f7ce97fa700 (LWP 12042))
Thread 9 (Thread 0x7f7ce9ffb700 (LWP 12041))
Thread 8 (Thread 0x7f7cea7fc700 (LWP 12040))
Thread 7 (Thread 0x7f7ceaffd700 (LWP 12039))
Thread 6 (Thread 0x7f7ceb7fe700 (LWP 12038))
Thread 5 (Thread 0x7f7cebfff700 (LWP 12037))
(gdb) (gdb)
Created attachment 344799 [details] tracker extract backtrace
$ tracker --version Tracker 1.10.4
Thanks for the bug report, and the backtrace. Thread 17 is the interesting one here. That path might indeed result expensive with huge PNGs, as we have to decompress the image in memory in order to access the metadata at the end of the file. I wonder if we can serialize the parsing somehow so we don't need allocating that much memory at once.
Pushed a fix to git master. The following fix has been pushed: d54665c tracker-extract: Avoid allocating full image in memory at once
Created attachment 346928 [details] [review] tracker-extract: Avoid allocating full image in memory at once Just read it line by line reusing the same buffer, it will still let us to fetch metadata at the end of the file.
Created attachment 347449 [details] tracker-extract backtrace
Carlos, thanks. Can you also look at fresh backtrace. It same issue or nor?
Yes, this seems the same issue. The backtrace is captured at a slightly later time, after it allocated memory for all image rows, while it is decompressing the image data in these. I think at that point not much extra memory is needed, although this step could be cpu intensive with huge images.