GNOME Bugzilla – Bug 776817
unreasonably long runtime for a crafted file
Last modified: 2018-05-22 13:21:50 UTC
The attached file takes unreasonably long time to load with pixbuf-read. I tried to profile with gprof, but it shows an empty profile for me. I guess I'm just doing things wrongly. callgrind eventually decided to commit suicide: ==28814== brk segment overflow in thread #1: can't grow to 0x4a7e000 success ==28814== ==28814== Process terminating with default action of signal 27 (SIGPROF) ==28814== at 0x54D321F: write_gmon (gmon.c:354) ==28814== by 0x54D3999: _mcleanup (gmon.c:422) ==28814== by 0x5404FF7: __run_exit_handlers (exit.c:82) ==28814== by 0x5405044: exit (exit.c:104) ==28814== by 0x53EB836: (below main) (libc-start.c:325) ==28814== ==28814== Events : Ir ==28814== Collected : 610590616710 ==28814== ==28814== I refs: 610,590,616,710 fish: “valgrind --tool=callgrind ./te…” terminated by signal SIGPROF (Profiling timer expired) It still showed this, though: >callgrind_annotate callgrind.out.28814 -------------------------------------------------------------------------------- Profile data file 'callgrind.out.28814' (creator: callgrind-3.11.0) -------------------------------------------------------------------------------- I1 cache: D1 cache: LL cache: Timerange: Basic block 0 - 106893912868 Trigger: Program termination Profiled target: ./tests/.libs/pixbuf-read longfile (PID 28814, part 1) Events recorded: Ir Events shown: Ir Event sort order: Ir Thresholds: 99 Include dirs: User annotated: Auto-annotation: off -------------------------------------------------------------------------------- Ir -------------------------------------------------------------------------------- 610,582,991,394 PROGRAM TOTALS -------------------------------------------------------------------------------- Ir file:function -------------------------------------------------------------------------------- 258,203,389,650 gdk-pixbuf/pixops/pixops.c:scale_line [/tmp/gdkpb/lib/libgdk_pixbuf-2.0.so.0.3602.0] 206,236,767,397 gdk-pixbuf/pixops/pixops.c:0x000000000006a7b0 [/tmp/gdkpb/lib/libgdk_pixbuf-2.0.so.0.3602.0] 95,011,180,723 gdk-pixbuf/pixops/pixops.c:pixops_process [/tmp/gdkpb/lib/libgdk_pixbuf-2.0.so.0.3602.0] 47,350,361,178 gdk-pixbuf/pixops/pixops.c:process_pixel [/tmp/gdkpb/lib/libgdk_pixbuf-2.0.so.0.3602.0]
Created attachment 342771 [details] long running file
It's a simili-PNM file: (gdb) p context->width $1 = 8 (gdb) p context->height $2 = 87201212 That's about 2.6GB of image. It fails in 0.1sec on my slow laptop without callgrind. I have no idea how much memory would be needed to run this through callgrind though.
FWIW: This is my experience on a Core-i7 2GHz something machine: $ time -v ./tests/pixbuf-read /tmp/bug776817.data /tmp/bug776817.data success Command being timed: "./tests/pixbuf-read /tmp/bug776817.data" User time (seconds): 33.91 System time (seconds): 0.06 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:33.97 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0 Average total size (kbytes): 0 Maximum resident set size (kbytes): 70144 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 51217 Voluntary context switches: 30 Involuntary context switches: 164 Swaps: 0 File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0 Page size (bytes): 4096 Exit status: 0 That's about 300 times slower than what you are reporting. Oh, and I crashed nautilus, because Epiphany stored the file in my downloads folder without asking... Do you think it's NOTABUG then?
Huh. It shows up as an 8x82 QTIF image on my system, not PNM. This requires further investigation.
It's detected as a PNM inside a QTIF. Sigh, no, that's not something that would have displayed on a Mac. I've found, in the wild, TIFF-in-QTIF, RAW-in-QTIF and JPEG-in-QTIF. We don't support the "RAW-in-QTIF" format, and I don't know of any other formats that we should be supporting. The IDSC atom which is supposed to identify the image type isn't always there either. A couple of things: - we should make it easier to create a sub-GdkPixbufLoader. The code needed in the QTIF and icns loaders is too big (it's super simple in ANI, because we never expect big buffers), and we want it for ICO too (see bug 551026) - we should be able to restrict which module actually gets loaded in GdkPixbufLoaders, to avoid the above. - and we should add support for the RAW-in-QTIF format which seems used quite a bit[1]. File format: http://xhelmboyx.tripod.com/formats/qti-layout.txt https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenA/QTFFAppenA.html Example files: http://fileformats.archiveteam.org/wiki/QTIF
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/60.