GNOME Bugzilla – Bug 472770
Load image -> Crash!
Last modified: 2007-09-07 13:32:10 UTC
1. Set monitor DPI to 96 in gimp. Disable Dot per Dot (by default, or on the image window). (note that enabling Dot Per Dot does not fix this crash. I specify to disable it only for the purposes of consistency.) 2.Load an image that is 192 dpi, then GIMP crashes. 2.or, load an image that is 96 dpi, and use 'scale image' to set the dpi to 192x192 -> gimp crashes. The change causing this problem has almost certainly occurred within the last 2 days. A few images are attached: *One that causes the crash, one which doesn't. Both are 192x192 dpi, 1280x960 pixels. *The XCF that the crash-causing PNG is based on - opening this causes a crash also. Note that thumbnailing still works fine -- the crash occurs after the image window opens, but before the image is shown.
Created attachment 94796 [details] 192dpi PNG that breaks GIMP gthumb and gimp's thumbnailing display this correctly, with no trouble.
Created attachment 94797 [details] source xcf xcf that the png was extracted from. Also causes GIMP to crash. xcftools displays this xcf correctly and also was able to extract all layers correctly.
Created attachment 94798 [details] 192dpi, 1280x960 xcf that doesn't crash gimp xcfview disrespects the DPI setting on this, but otherwise displays it correctly. I suspect this bug is caused by improper copy+paste for GRAYA scaling. Note: opening this a second time *DOES* crash the GIMP.
Oops, looks like this was caused by the latest scale-region.c from bug #464466. I thought I'd tested it correctly, but apparently not. Closing.
No, actually some really dodgy bug is happening, and it just happened to synchronize with my tests. After removing the experimental scale-region.c, running 'make clean; make;make install', crashing still happened. AAARGH. Reopening.
nope, sorry. It's most likely a subtle incompatibility between gj's scale-region.c and the recent changes to GimpDisplayShell. Closing, finally.
Not finally; reopened; the crash just occurs whenever it feels like it regardless of which scale-region.c I'm using. Sorry about the noise. THIS JUST BOILS DOWN TO: WITH A CLEAN COMPLETELY FRESH COMPILE+INSTALLATION OF SVN GIMP, GIMP JUST CRASHES ARBITRARILY UPON OPENING AN IMAGE, WHETHER THROUGH THE OPEN DIALOG OR GIMP-REMOTE. IT IS POSSIBLE THAT THE CRASH OCCURS PER-SESSION (that is, it either will crash on any image that you could possibly open for a given session, or it won't crash on any of the images you could open). GAH. >_< Anyhow, this appears to be real, but I'm at a loss to explain it. Hopefully it is easily reproduced. The DOT FOR DOT setting is irrelevant, it's crashed with the default set either way. The DPI setting is probably also irrelevant.
Okay, I've tested with 2.4rc1, and it doesn't exhibit this crashing behaviour. So the crash-causing code has been introduced after the rc1 release was made. (I also adjusted OS field to be accurate. The bug is probably present on all platforms -- but I *know* it is evident on Linux.)
Adjusting summary to be more accurate. Other details: OS: Ubuntu 6.06, running on a AMD Duron with 1gb of RAM Window Manager: dwm GLib 2.14.1 (SVN) GTK+ 2.11.7 (SVN)
2.4rc1: doesn't exhibit this bug. 2.4rc2: does exhibit this bug. Stacktrace later.
I can't reproduce the crash with rc2 on Windows, neither with the XCF nor with the PNG file.
In case I haven't been perfectly clear: The crash happens when opening virtually any image. It seems to be random luck if a crash DOESN'T occur. Really, steps to reproduce are simpler than I thought: 1. Load image 2. See GIMP crash after the image window appears, before the image is displayed in it. (To me, this points at recent changes in gimpdisplayshell.c causing the crash.) I'll try to mark all attachments as obsolete. It seems I have to recompile RC2 again before I can reinstall it; I'll have a stacktrace sometime today.
I just found out: This crash never occurs for indexed images, only RGB/RGBA/GRAY/GRAYA. And sometimes, it won't occur -- ie. I can open the same file twice, and the first time it might be okay, the second time it crashes immediately. It looks like it's a tile refcounting bug: tile_release (tile=0x0, dirty=0) at tile.c:176 176 tile->ref_count--; But that may be misleading, since tile_manager_get is returning a NULL tile:
+ Trace 160766
I've tried opening different images, and the backtrace remains essentially the same.
(In reply to comment #13) > In case I haven't been perfectly clear: The crash happens when opening > virtually any image. Then you should probably mark the attachments as obsolete.
Created attachment 95045 [details] makes other attachments obsolete. Ignore this file. I said I'd try, but I haven't been able to; the Edit link doesn't seem to allow it. It seems to me that the only way to do so is to make a dummy attachment which obsoletes them. So I am doing that.
What is odd is that your stacktrace contains a call to `gimp_image_pick_color'. That function is not called for me when I open an image. If you clear your ~/.gimp-2.4, does it help? If not, try to remove gimp stuff from PREFIX/lib|share|bin and reinstall, just to make sure you start fresh. Let's try to sort this out for 2.4.
The stack trace is entirely reasonable. It crashes when the "Cursor" dockable wants to update the color under the cursor of the newly opened image. However, I cannot reproduce this even with the cursor dockable open.
Argh, I see the bug. It's all in the stack trace and caused by my fix for bug #472170. However, while I see the bug in the stack trace, I still can't reproduce it... will look into fixing it anyway.
Created attachment 95093 [details] my sessionrc Attaching a copy of my sessionrc in the hope it helps to reproduce the bug.
I have Gimp crashes on my Windows XP installation with RC1 and RC2 when gimp is about to update the last tile in the bottom right corner. With RC1 and RC2 this happens only when opening large images (3000x2000), not with small ones that fit 100% on the screen. With RC1 this happened from time to time, with RC2 always. Since the tile update is so slow (*weap*) on Windows I can watch the tile update progress until it reaches the bottom right corner and then - *crash*. Interestingly on my Vista Notebook RC1 runs almost stable ?!?! I haven't tried RC2 yet.
I just verified that the crash happens on my XP installation when displaying the large image with 33% zoomed view - not in 100% view.
Jörg, I think your crashes are unrelated, please check bug #469831 instead. I'm very sure this fixes the bug, but I could never reproduce it. Closing as FIXED anyway, please reopen if it's still there. 2007-09-07 Michael Natterer <mitch@gimp.org> * app/base/tile-manager.c (read_pixel_data_1): use a temporary variable to store the return value of tile_manager_get() instead of assigning to tm->cached_tile directly to make sure tm->cached_num and tm->cached_tile are always in a consistent state (the requested tile might be invalid and needs to be validated, which would call tile_manager_get() recursively, which in turn would clear the cached tile). Fixes bug #472770.
Works for me. Thanks.