Comments (15)
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.
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.
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.
Thanks, now I can confirm eom 1.10.3 indeed crashes on this file.
from eom.
Firefox also fails with it...
from eom.
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.
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.
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.
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.
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.
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.
What is the status of this bug? It has now CVE-2013-7447 assigned.
from eom.
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.
Thank you. I indeed concerned about eom code. Now it gets fixed by Mate part it is all ok.
from eom.
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)
- Single image argument should not load entire folder HOT 2
- Show image's full path name on window title bar
- [feature]partial support of videos, for gif like videos
- [feature] image number in fullscreen
- Type is wrong of svg image with .pdf ending
- RFC: re-examine libexif version requirement HOT 4
- eom failed to build with itstools 2.0.7 built with python3 HOT 1
- [feature request] Rename image in EOM HOT 1
- EOM puts wrong file name on "Save As..."
- Incorrect/corrupt image displayed for floating-point TIFF file
- [Feature request] Add plugins "map", "fit to width" & "slideshow" from Yaakov Selkowitz
- [feature request] - support to panorama 360 (photosphere)
- tried to connect to the internet HOT 8
- install problem HOT 7
- Memory leak issue in EOM when opening JPEG with near maximum pixel resources HOT 2
- [FEATURE] remove scrollbars in full screen
- libpeas-2 comes with API and ABI changes and and removal of the GTK interfaces. HOT 5
- [feature] EOM api to determine current image validity status
- [bug] _automatic orientation_ should be disabled when `libexif` not available at compile time
- EOM window overflows past the screen for certain image resolutions HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eom.