Giter VIP home page Giter VIP logo

Comments (15)

ivo-s avatar ivo-s commented on August 28, 2024

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

from eom.

monsta avatar monsta commented on August 28, 2024

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 😄

from eom.

vigri avatar vigri commented on August 28, 2024

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"

from eom.

monsta avatar monsta commented on August 28, 2024

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

from eom.

infirit avatar infirit commented on August 28, 2024

Firefox also fails with it...

from eom.

monsta avatar monsta commented on August 28, 2024

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)

from eom.

monsta avatar monsta commented on August 28, 2024

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

from eom.

ivo-s avatar ivo-s commented on August 28, 2024

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.

from eom.

monsta avatar monsta commented on August 28, 2024

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).

from eom.

monsta avatar monsta commented on August 28, 2024

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...

from eom.

monsta avatar monsta commented on August 28, 2024

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).

from eom.

tarakbumba avatar tarakbumba commented on August 28, 2024

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

from eom.

monsta avatar monsta commented on August 28, 2024

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.

from eom.

tarakbumba avatar tarakbumba commented on August 28, 2024

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

from eom.

monsta avatar monsta commented on August 28, 2024

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.

from eom.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.