EOM crashes when trying to open a large PNG file #93

vigri · 2015-07-26T22:46:13Z

Hello,

I would like to report a bug concerning EOM version 1.8.0

When trying to open a large PNG file 27.000px x 27.000px) EOM crashes.

Environment:
Debian 8.1 x64
EOM 1.8.0

I've been able to catch a backtrace using gdb:

Program received signal SIGSEGV, Segmentation fault.                                                                                                                                                               
[Switching to Thread 0x7fd046086700 (LWP 57178)]                                                                                                                                                       >0x00007fd04fc042f0 in mate_desktop_thumbnail_scale_down_pixbuf () from /usr/lib/x86_64-linux-gnu/libmate-desktop-2.so.17                                                                                           
(gdb) bt
#0  0x00007fd04fc042f0 in mate_desktop_thumbnail_scale_down_pixbuf () from /usr/lib/x86_64-linux-gnu/libmate-desktop-2.so.17
#1  0x0000000000440375 in eom_thumbnail_load ()
#2  0x0000000000441481 in ?? ()
#3  0x00000000004405b1 in ?? ()
#4  0x00007fd04ca51935 in g_thread_proxy (data=0xbf2850) at /tmp/buildd/glib2.0-2.42.1/./glib/gthread.c:764
#5  0x00007fd04b69a0a4 in start_thread (arg=0x7fd046086700) at pthread_create.c:309
#6  0x00007fd04b3cf04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Please let me know if you need the test file.

Best regards

The text was updated successfully, but these errors were encountered:

ivo-s · 2015-08-07T09:39:39Z

Hello, I wonder whether this issue is connected to the one I am having:
#88

I also found a possibly related bug on Eye of Gnome:
https://bugs.launchpad.net/ubuntu/+source/eog/+bug/877279

monsta · 2015-08-28T10:12:32Z

Please let me know if you need the test file.

Yes, please post it so we can try reproducing the issue - I don't have such huge images around 😄

vigri · 2015-09-17T09:21:09Z

Unfortunately GitHub doesn't let me upload the Image.

Please check this link here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794424

At the bottom you see "27000_27000_1437947845.png".
Right klick it and select "save as"

monsta · 2015-09-17T09:25:20Z

Thanks, now I can confirm eom 1.10.3 indeed crashes on this file.

infirit · 2015-09-17T09:29:29Z

Firefox also fails with it...

monsta · 2015-09-17T10:15:45Z

Backtrace from eom 1.10.3 in LMDE 2 (based on Debian Jessie):

(gdb) bt full
#0  g_logv (log_domain=0x7ffff37c718e "GLib", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=args@entry=0x7fffffffde80)
    at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1046
        domain = 0x0
        data = 0x0
        depth = 0
        log_func = 0x7ffff37865c0 <g_log_default_handler>
        domain_fatal_mask = <optimized out>
        masquerade_fatal = 0
        test_level = <optimized out>
        was_fatal = <optimized out>
        was_recursion = <optimized out>
        msg = 0x7fffd40008c0 "/tmp/buildd/glib2.0-2.42.1/./glib/gmem.c:103: failed to allocate 18446744072330584320 bytes"
        msg_alloc = 0x7fffd40008c0 "/tmp/buildd/glib2.0-2.42.1/./glib/gmem.c:103: failed to allocate 18446744072330584320 bytes"
        i = 2
#1  0x00007ffff3786f6f in g_log (log_domain=log_domain@entry=0x7ffff37c718e "GLib", log_level=log_level@entry=G_LOG_LEVEL_ERROR, 
    format=format@entry=0x7ffff37d0ac0 "%s: failed to allocate %lu bytes") at /tmp/buildd/glib2.0-2.42.1/./glib/gmessages.c:1079
        args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fffffffdf60, reg_save_area = 0x7fffffffdea0}}
#2  0x00007ffff37857fc in g_malloc (n_bytes=n_bytes@entry=18446744072330584320) at /tmp/buildd/glib2.0-2.42.1/./glib/gmem.c:102
        mem = <optimized out>
#3  0x00007ffff6c9dd82 in IA__gdk_cairo_set_source_pixbuf (cr=0x7fffd000b3e0, pixbuf=<optimized out>, pixbuf_x=0, pixbuf_y=0)
    at /build/gtk+2.0-czQfyJ/gtk+2.0-2.24.25/gdk/gdkcairo.c:213
        width = 27000
        height = 27000
        gdk_pixels = 0x7fff4da50010 ""
        gdk_rowstride = 81000
        n_channels = <optimized out>
        cairo_stride = 108000
        cairo_pixels = <optimized out>
        format = CAIRO_FORMAT_RGB24
        surface = <optimized out>
        key = {unused = 0}
        j = <optimized out>
#4  0x0000000000437f93 in create_surface_from_pixbuf (pixbuf=0x8e31e0, view=0x8e31e0) at eom-scroll-view.c:209
        surface = 0x958d70
        cr = 0x7fffd000b3e0
#5  update_pixbuf (view=view@entry=0x8bd0d0, pixbuf=<optimized out>) at eom-scroll-view.c:2066
        priv = 0x8bd000
#6  0x000000000043adc3 in eom_scroll_view_set_image (view=0x8bd0d0, image=0x86ad40) at eom-scroll-view.c:2389
        priv = 0x8bd000
        __FUNCTION__ = "eom_scroll_view_set_image"
#7  0x0000000000425205 in eom_window_display_image (window=0x1000, image=0x0) at eom-window.c:879
        priv = 0x750170
        file = 0x0
        __FUNCTION__ = "eom_window_display_image"
#8  0x0000000000425ce7 in eom_job_load_cb (job=0x8c6740, data=0x7502f0) at eom-window.c:1302
        window = 0x7502f0
        priv = 0x750170
        action_undo = 0x7502f0
        action_save = 0x8cacf0
        __FUNCTION__ = "eom_job_load_cb"
#9  0x00007ffff3a55474 in _g_closure_invoke_va (closure=0x1000, closure@entry=0x8cba90, return_value=return_value@entry=0x0, instance=0x0, 
    instance@entry=0x8c6740, args=0x206e0, args@entry=0x7fffffffe320, n_params=-738195168, param_types=0x7fffd4000070)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gclosure.c:831
        marshal = 0x0
        marshal_data = 0x7fffd4000920
        __FUNCTION__ = "_g_closure_invoke_va"
#10 0x00007ffff3a6f087 in g_signal_emit_valist (instance=0x8c6740, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffe320)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3218
        return_accu = <optimized out>
        accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, 
---Type <return> to continue, or q <return> to quit---
              v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        accumulator = 0x0
        emission = {next = 0x0, instance = 0x8c6740, ihint = {signal_id = 257, detail = 0, run_type = G_SIGNAL_RUN_FIRST}, state = EMISSION_RUN, 
          chain_type = 9198624}
        signal_id = 257
        instance_type = <optimized out>
        emission_return = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, 
              v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}}
        rtype = 4
        static_scope = 0
        fastpath_handler = <optimized out>
        closure = 0x8cba90
        run_type = <optimized out>
        l = <optimized out>
        fastpath = <optimized out>
        instance_and_params = <optimized out>
        signal_return_type = <optimized out>
        param_values = <optimized out>
        i = <optimized out>
        n_params = <optimized out>
        __FUNCTION__ = "g_signal_emit_valist"
#11 0x00007ffff3a6f9df in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0)
    at /tmp/buildd/glib2.0-2.42.1/./gobject/gsignal.c:3365
        var_args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fffffffe400, reg_save_area = 0x7fffffffe340}}
#12 0x000000000044132b in eom_job_finished (job=<optimized out>) at eom-jobs.c:136
        __FUNCTION__ = "eom_job_finished"
#13 0x000000000043f3ac in notify_finished (job=0x8c6740) at eom-job-queue.c:66
No locals.
#14 0x00007ffff377fb6d in g_main_dispatch (context=0x6c2970) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3111
        dispatch = 0x7ffff377c6c0 <g_idle_dispatch>
        prev_source = 0x0
        was_in_call = 0
        user_data = 0x8c6740
        callback = 0x43f390 <notify_finished>
        cb_funcs = <optimized out>
        cb_data = 0x7fffd0010a40
        need_destroy = <optimized out>
        source = 0x7fffd0010e30
        current = 0x687560
        i = 0
#15 g_main_context_dispatch (context=context@entry=0x6c2970) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3710
No locals.
#16 0x00007ffff377ff48 in g_main_context_iterate (context=0x6c2970, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3781
        max_priority = 200
        timeout = 0
        some_ready = 1
        nfds = <optimized out>
        allocated_nfds = 3
        fds = 0x8c5d30
#17 0x00007ffff3780272 in g_main_loop_run (loop=0x8c5d10) at /tmp/buildd/glib2.0-2.42.1/./glib/gmain.c:3975
        __FUNCTION__ = "g_main_loop_run"
#18 0x00007ffff7065597 in IA__gtk_main () at /build/gtk+2.0-czQfyJ/gtk+2.0-2.24.25/gtk/gtkmain.c:1257
        tmp_list = 0x0
        functions = 0x0
        init = <optimized out>
        loop = 0x8c5d10
#19 0x000000000041db7b in main (argc=1, argv=0x7fffffffe6f8) at main.c:281
        error = 0x0
        ctx = <optimized out>
(gdb)

monsta · 2015-09-17T11:31:03Z

I really don't get it... the crash happens here, during g_malloc call:

  cairo_stride = cairo_format_stride_for_width (format, width);
  cairo_pixels = g_malloc (height * cairo_stride);

The backtrace shows us the values:

        width = 27000
        height = 27000
        cairo_stride = 108000

Then g_malloc should try to allocate 27000 x 108000 = 2916000000 bytes. Why does it try to allocate 18446744072330584320 bytes instead? 😕

Hmm... Looks like upper 32 bits got screwed up...

2916000000           == 0x00000000adcea100
18446744072330584320 == 0xffffffffadcea100

ivo-s · 2015-09-17T12:04:31Z

Sorry if I sound too noobish, but to me it seems the problem is in integer types of variables height and cairo_stride. According to your source code, both are 32-bit signed integers. That means an overflow during the multiplication, which will result in 27000*108000 = -1378967296. This will then get cast into unsigned long for g_malloc, resulting in 0xffffffffadcea100, which is the humongous number. Making cairo_stride unsigned or increasing the byte size should fix it.

monsta · 2015-09-17T12:08:54Z

Ah dammit, they're indeed signed 32-bit ones, I completely overlooked that 😆
Thanks. I think we can also solve it by applying this patch to GDK (it will simply avoid the multiplication of these signed 32-bit integers).

monsta · 2015-09-17T13:17:32Z

Ok, filed this bug report in order to get the patch into Debian Jessie.
Of course this needs to be added upstream as well - but we'll still need to prepare patches for current stable releases of Debian and Ubuntu...

monsta · 2015-09-17T13:36:39Z

Ah, forgot to add: after applying that patch to GTK+2 and trying eom with the large image again, I had my desktop almost frozen... I could alt-tab and see window borders, but no window contents, and everything was horribly slow. Looks very close to what's described in that Ubuntu bug report mentioned above.
I didn't need to reset the system though: eventually eom triggered some X error and crashed (or was killed), and soon the situation was back to normal.
I'll see what I can do about this too (possibly adapt some patches from this eog report).

tarakbumba · 2016-02-11T07:37:26Z

What is the status of this bug? It has now CVE-2013-7447 assigned.

monsta · 2016-02-11T08:14:19Z

Ask your distro's GTK+2 maintainers to apply the patch. It's not on eom's side.

But if you're wondering about eom mentioned in the list here, it's about another part of code (print preview). I've applied the fix to that part in b7849cc.

tarakbumba · 2016-02-11T12:11:07Z

Thank you. I indeed concerned about eom code. Now it gets fixed by Mate part it is all ok.

monsta · 2016-04-04T08:30:00Z

Ok, GTK+2 is now patched in almost all current Debian and Ubuntu releases. The fix is also applied upstream and will be available in the next GTK+2 release.

So, eom shouldn't crash anymore on opening some large files.

However, you still might get some issues (slowdowns, blank window, etc.) while displaying these files. These issues are separate from this one. Please leave your comments at #88 or #105, depending on the issue.

infirit added the confirmed label Sep 17, 2015

monsta mentioned this issue Sep 29, 2015

Eom have a hard time displaying with high resolution images. #105

Closed

monsta closed this as completed Apr 4, 2016

monsta mentioned this issue May 12, 2016

Not displaying a large image and menu items going blank on mouseover #88

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

EOM crashes when trying to open a large PNG file #93

EOM crashes when trying to open a large PNG file #93

vigri commented Jul 26, 2015

ivo-s commented Aug 7, 2015

monsta commented Aug 28, 2015

vigri commented Sep 17, 2015

monsta commented Sep 17, 2015

infirit commented Sep 17, 2015

monsta commented Sep 17, 2015

monsta commented Sep 17, 2015

ivo-s commented Sep 17, 2015

monsta commented Sep 17, 2015

monsta commented Sep 17, 2015

monsta commented Sep 17, 2015

tarakbumba commented Feb 11, 2016

monsta commented Feb 11, 2016

tarakbumba commented Feb 11, 2016

monsta commented Apr 4, 2016

EOM crashes when trying to open a large PNG file #93

EOM crashes when trying to open a large PNG file #93

Comments

vigri commented Jul 26, 2015

ivo-s commented Aug 7, 2015

monsta commented Aug 28, 2015

vigri commented Sep 17, 2015

monsta commented Sep 17, 2015

infirit commented Sep 17, 2015

monsta commented Sep 17, 2015

monsta commented Sep 17, 2015

ivo-s commented Sep 17, 2015

monsta commented Sep 17, 2015

monsta commented Sep 17, 2015

monsta commented Sep 17, 2015

tarakbumba commented Feb 11, 2016

monsta commented Feb 11, 2016

tarakbumba commented Feb 11, 2016

monsta commented Apr 4, 2016