GNOME Bugzilla – Bug 469567
GIMP crashes when displaying certain image sizes
Last modified: 2008-10-30 19:57:28 UTC
GIMP 2.4 RC1 on Windows XP, compiled with MinGW. Also tested provided Windows installer - problem persists. GIMP crashes frequently with "memory cannot be read" message when cropping the image, sometimes also during other operations. Tested on two PCs, also with clean .gimp-2.4 profile. Steps to reproduce: 1. Load an image from 8MP camera (link to test image provided below). 2. View > Zoom > Fit image to window. 3. Select crop tool. 4. Draw rectangle and press Enter. If GIMP doesn't crash, undo and repeat this step several times. I usually have crash on first or second attempt. This happens for various files, TIFF and JPG. Sometimes GIMP crashes during other operations: perspective correction, move layer, etc. NOTE: if cropping is done on 1:1 display, program usually doesn't crash. I think that problem is not related to cropping but to redrawing the processed image. I observed this situation: I'm doing perspective correction, I click Transform, progress bar is running, image slowly redraws, after that GIMP crashes. I've compiled and used various GIMP 2.3.x releases since 2.3.12 and never had problems like this. In fact, GIMP 2.3.19 still processes the same images without any crashes. Here is test image that makes GIMP crash most often (24 MB TIFF file): http://tinyurl.com/2g7gdx The only output from Dr.MinGW is this: gimp-2.4.exe caused an Access Violation at location 0044aa05 in module gimp-2.4.exe Reading from location 05372003. Registers: eax=05371ffc ebx=000000c0 ecx=000000ff edx=05372000 esi=00000021 edi=0022f6b0 eip=0044aa05 esp=0022f510 ebp=0022f5c8 iopl=0 nv up ei pl nz ac po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000216 Call stack: 0044AA05 gimp-2.4.exe:0044AA05 0044D4D5 gimp-2.4.exe:0044D4D5 0044D942 gimp-2.4.exe:0044D942 00457F21 gimp-2.4.exe:00457F21 0045B520 gimp-2.4.exe:0045B520 60578E62 libgtk-win32-2.0-0.dll:60578E62 gtk_marshal_VOID__UINT_STRING 62743935 libgobject-2.0-0.dll:62743935 g_closure_invoke 62756FB5 libgobject-2.0-0.dll:62756FB5 g_signal_has_handler_pending 62757ABC libgobject-2.0-0.dll:62757ABC g_signal_emit_valist 62757FD6 libgobject-2.0-0.dll:62757FD6 g_signal_emit 6069C434 libgtk-win32-2.0-0.dll:6069C434 gtk_widget_activate 60577622 libgtk-win32-2.0-0.dll:60577622 gtk_main_do_event 6B05C052 libgdk-win32-2.0-0.dll:6B05C052 gdk_window_clear_area_e 6B05C11B libgdk-win32-2.0-0.dll:6B05C11B gdk_window_process_all_updates 604DE0F9 libgtk-win32-2.0-0.dll:604DE0F9 gtk_container_check_resize 672DEA67 libglib-2.0-0.dll:672DEA67 g_main_context_dispatch 672DFF3B libglib-2.0-0.dll:672DFF3B g_main_context_acquire 672E011A libglib-2.0-0.dll:672E011A g_main_loop_run 004015B0 gimp-2.4.exe:004015B0 004023D6 gimp-2.4.exe:004023D6 00401237 gimp-2.4.exe:00401237 004012A8 gimp-2.4.exe:004012A8 7C816FD7 kernel32.dll:7C816FD7 RegisterWaitForInputIdle
Created attachment 94335 [details] Stack trace from GIMP OK, finally got the stack trace. File gimpdisplayshell-render.c was updated with version from SVN (rev. 23365) but it didn't change anything. I wasn't able to reproduce this bug on Linux so it may be Windows specific.
Is it reproducable from latest trunk? (the complete source tree, not just gimpdisplayshell-render.c)
Yes, it's reproducable from latest trunk. I've checked various versions of gimpdisplayshell-render.c. Up to revision 23251 (inclusive) GIMP works fine. Revision 23278 is the first one causing crashes: Revision 23278 Modified Wed Aug 15 21:29:43 2007 UTC File length: 42562 byte(s) * app/display/gimpdisplayshell-render.c: added a bilinear filtering like weighting of neighbourhood pixels for approximating the downsampling from the next larger level in the projection mipmap. Also some general code cleanup.
I still suspect this is a duplicate of bug #470282. Just to be sure: You say you have checked various versions of gimpdisplayshell-render.c, but I hope you mean various versions of the complete source tree, right? Also, I understand you have discovered that it crashes on revision 23278, but to be sure; you did continue to test up to HEAD, right? If you are still able to reproduce it, please provide a very detailed step-by-step on how to reproduce it all the time. And by detailed I mean detailed :) Thanks
Ok, so let me clarify this. Procedure is described in original report. Load image from the link I provided. Make it fit to window (Ctrl+Shift+E). Then crop, undo, crop, undo... until it crashes. For me, crop-undo-crop is usually enough to casue crash. Now, 2.3.19 - works without problems. 2.4 RC1 - crashes. Latest SVN (checked on Aug 26) - crashes. Latest SVN with ONLY gimpdisplayshell-render.c reverted to rev. 23251 - does not crash. It seems that the procedure for bilinear filtering of zoomed out image sometims works well and sometimes causes crash. If you still can't reproduce this bug with the image I provided - OK, I'll stick with 2.3.19 which is stable for me. When next version is out I'll let you know if it works. Thank you.
That was not detailed though. Detailed would be: What zoom level did you use (Fit to window causes different zoom levels for different screen/window sizes). Due to the nature of the code, it probably crashes for a specific image size, so experiement a bit to find a crop rectangle size and position that causes the crash and please report that as well. Also, Preferences -> Tile cache size seems to create different results, so your setting there would also be useful to know.
It took me some time to compile the SVN trunk and do some testing. Here are the results. -------------------- GIMP 2.4 RC1 compiled from full SVN trunk downloaded on 2007-08-28 21:50 GMT. Compiled with MinGW/MSYS (GCC 3.4.5 mingw special) using GTK+ 2.10.14 and GLib 2.14.0, runtimes of the same versions are used for running gimp-2.4.exe. Compiled and tested on PC with 512 MB RAM, Windows XP Pro. Test image: TIFF file, 3280x2450 pixels, 8 bit, single layer, LZW. Image size after decompressing: 73.7 MB (as reported by GIMP). Tested on clean .gimp-2.4 profile and clean GIMP instalation. Test procedure was repeated crop-undo operations. Undo parameters: 5 levels, max. 64 MB. --- Tile cache size = 1024 MB (default GIMP value). Tesing at different zoom levels. Crashed at: 23% 63% 75% 96% 125% Did not crash at: 25% 50% 100% --- Zoom level set to 23% (Fit Image in Window), testing different tile cache sizes. Crashed for tile cache size = 128 MB, 256 MB, 512 MB, 768 MB, 1024 MB, 1536 MB, 2048 MB (each tested one). Number of successive crop and undo operations that cause a crash is not always the same for a given tile cache size setting, it seems to be random (1-5,usually 2-3). --- Any size of crop rectangle causes a crash (full image, c.a. 90 % of the image, window content of the image zoomed at 75%, etc.). Crashes observed also for other files having similar pixel size, also for JPEGs. -------------------- For me it's evident that crashes are not related for cropping, as I suspected when I submitted the original report. I was cropping many images and GIMP crashed so I thought that crop procedure is broken. Now it's evident for me that the procedure from gimpdisplayshell-render.c that performs filtering for "uneven" zoom levels (not 25%, 50%, etc) is to blame. Or maybe it's because of a bug in memory management in GIMP. What is strange, crashes are random, although very frequent. Link to my image is provided in original report, stack trace in comment #1. Hope it's detailed enough now. If not, let me know. I'm leaving this as NEEDINFO, when RC2 is out I'll recheck this and give information here.
I'm reopening this because RC2 still crashes in the same situation with identical symptoms.
One additional note. I've downloaded GIMP RC2 installer from Sourceforge and installed it on brand new Win XP SP2 machine (GIMP was not installed on it before). I've tested my image and it also crashed, although it took more crop-and-undo operations, about 8. This is probably because this machine has more RAM (1 GB). I could attach crash dump form Windows but I think it's useless. Can anyone test this? Please install RC2 on Windows machine with 1GB RAM or less, download my test image (see original report for link), set the window to zoom that is not 25%, 50& or 100% and then do repeated crop-undo (marking about 90% of the window for crop). If GIMP doesn't crash after 20 crop-and-undos, then it's probably my own fault. Note that it has to be tested on Windows XP, I couldn't reproduce this crash on Linux. If any of the developers observe the crash on their machine, please set this bug to confirmed. Also, I'm reassigning it to RC2.
Duplicate of bug #469831?
Also something that deserves some additional attention before 2.4.
Grzegorz, did you try the latest svn (rev. 23480)? I had crashes with RC2 as well but now it seems to be ok. It might have to do with fixing this bug (http://bugzilla.gnome.org/show_bug.cgi?id=472770).
*** Bug 475214 has been marked as a duplicate of this bug. ***
Ad #12: no, it still crashes. Ari Pollak observed that these crashes occur on amd processors (bug 475214, comment #6). My CPU is Athlon XP 2600 so it may be true.
I duplicated the crash on my computer at 23% zoom using RC2. It also has an AMD processor. I have 512 MB of ram.
*** Bug 470282 has been marked as a duplicate of this bug. ***
Following the instructions from bug #475214, I got this warning (and many more) from valgrind: ==22174== Invalid read of size 1 ==22174== at 0x80C003F: render_image_tile_fault_one_row (gimpdisplayshell-render.c:945) ==22174== by 0x80C1E79: render_image_rgb_a (gimpdisplayshell-render.c:862) ==22174== by 0x80C2AA1: gimp_display_shell_render (gimpdisplayshell-render.c:275) ==22174== by 0x80B9250: gimp_display_shell_draw_area (gimpdisplayshell-draw.c:574) ==22174== by 0x80B47AD: gimp_display_shell_canvas_expose (gimpdisplayshell-callbacks.c:421) ==22174== by 0x42BAC0F: _gtk_marshal_BOOLEAN__BOXED (gtkmarshalers.c:84) ==22174== by 0x48EC721: g_closure_invoke (in /usr/lib/libgobject-2.0.so.0.1400.0) ==22174== by 0x48FD27C: (within /usr/lib/libgobject-2.0.so.0.1400.0) ==22174== by 0x48FE54E: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.1400.0) ==22174== by 0x48FE948: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.1400.0) ==22174== by 0x43CEDD7: gtk_widget_event_internal (gtkwidget.c:3915) ==22174== by 0x42B53F3: gtk_main_do_event (gtkmain.c:1533) ==22174== Address 0x99C3FBB is 3 bytes after a block of size 16,128 alloc'd ==22174== at 0x4023765: malloc (vg_replace_malloc.c:149) ==22174== by 0x4954635: g_malloc (in /usr/lib/libglib-2.0.so.0.1400.0) ==22174== by 0x82E99C1: tile_alloc (tile.c:222) ==22174== by 0x82E9A9D: tile_lock (tile.c:154) ==22174== by 0x82EAE0E: tile_manager_get (tile-manager.c:258) ==22174== by 0x80C09D6: render_image_tile_fault (gimpdisplayshell-render.c:1126) ==22174== by 0x80C1E79: render_image_rgb_a (gimpdisplayshell-render.c:862) ==22174== by 0x80C2AA1: gimp_display_shell_render (gimpdisplayshell-render.c:275) ==22174== by 0x80B9250: gimp_display_shell_draw_area (gimpdisplayshell-draw.c:574) ==22174== by 0x80B47AD: gimp_display_shell_canvas_expose (gimpdisplayshell-callbacks.c:421)
FWIW, I believe the stack trace is incorrect (I think the last function should be box_filter), though the last line number should be right; You have to build without -O2 to get a correct stack trace.
*** Bug 469831 has been marked as a duplicate of this bug. ***
2007-09-12 Øyvind Kolås <pippin@gimp.org> * app/display/gimpdisplayshell-render.c: (render_image_tile_fault), (render_image_tile_fault_one_row): clone the middle row/column when walking off the source drawable during downscaling. Probably fixes bug #469567.
Created attachment 95496 [details] Screenshot from rev. 23251 Now things got even worse. See the attached screenshot.
*** Bug 476385 has been marked as a duplicate of this bug. ***
Grzegorz, are you absolutely sure that there are no other changes in your tree, perhaps an SVN conflict caused by other patches you tried? I doubt that the recent changes could introduce the problem illustrated by that screenshot.
The commit mentioned in comment #20 seems to have silenced all the warnings from valgrind about reads outside allocated memory. Closing the bug as FIXED.
*** Bug 477676 has been marked as a duplicate of this bug. ***
*** Bug 477949 has been marked as a duplicate of this bug. ***
I'm writing just to inform that after recompiling the full SVN trunk with chnages mentioned in #20, the problem seems to be gone. Please disregard my comment #21. Thank you for support.