GNOME Bugzilla – Bug 555246
gimp crashes when a file is opened while a preview is generating
Last modified: 2008-11-22 00:12:14 UTC
2.6.0 crashes on trying to open an ImageMagick-generated JPG. (converted with -monochrome -normalize options from a larger .jpg) 2.4.x reads them just fine. Reading and then saving the file with IrfanView made the resulting JPG readable by GIMP. Sample file is available.
Please attach the file that crashes GIMP to this bug report.
Created attachment 120064 [details] JPEG that crashes 2.6.0 Here is the ImageMagick-modified JPG that crashes 2.6.0 on Windows. I suspect this is a recurrence of the libexif bug from earlier versions.
It seems that the original picture had the following EXIF data but the IrfanView-saved copy had NO EXIF data. Make - NIKON CORPORATION Model - NIKON D80 Orientation - Top left XResolution - 300 YResolution - 300 ResolutionUnit - Inch Software - Ver.1.10 DateTime - 2008:07:24 15:43:30 YCbCrPositioning - Co-Sited ExifOffset - 216 ExposureTime - 1/60 seconds FNumber - 6.30 ExposureProgram - Manual control ISOSpeedRatings - 320 ExifVersion - 0221 DateTimeOriginal - 2008:07:24 15:43:30 DateTimeDigitized - 2008:07:24 15:43:30 ComponentsConfiguration - YCbCr CompressedBitsPerPixel - 4 (bits/pixel) ExposureBiasValue - 0.00 MaxApertureValue - F 3.36 MeteringMode - Multi-segment LightSource - White fluorescent Flash - Not fired FocalLength - 28.00 mm UserComment - SubsecTime - 0 SubsecTimeOriginal - 0 SubsecTimeDigitized - 0 FlashPixVersion - 0100 ColorSpace - sRGB ExifImageWidth - 3872 ExifImageHeight - 2592 InteroperabilityOffset - 36022 SensingMethod - One-chip color area sensor FileSource - Other SceneType - Other CustomRendered - Normal process ExposureMode - Manual WhiteBalance - Manual DigitalZoomRatio - 1 x FocalLengthIn35mmFilm - 42 mm SceneCaptureType - Standard GainControl - None Contrast - Normal Saturation - Normal Sharpness - Normal SubjectDistanceRange - Unknown Maker Note (Vendor): - Data version - 0210 (808595760) ISO Setting - 320 Color Mode - COLOR Image Quality - FINE White Balance - FLUORESCENT Image Sharpening - AUTO Focus Mode - MANUAL Flash Setting - NORMAL Flash Mode - White Balance Adjustment - 196608 White Balance RB - 710 Exposure Adjustment - -301921280 Flash Compensation - 67072 ISO 2 - 320 Tone Compensation - AUTO Lens type - AF-D G Lens - 802 Flash Used - Not fired AF Focus Position - Center Bracketing - 65536 Color Mode - MODE1a Light Type - NATURAL Hue Adjustment - 0 Noise Reduction - OFF Total pictures - 1254 Optimization - NORMAL
The file loads fine for me on Linux using Ubuntus almost vanilla version of libexif 0.6.16. I'm not sure whether to close this as NOTGNOME or assign to the (Windows) Installer component.
I'll leave it up to ender to decide the fate of this bug report.
I can't reproduce the crash here. Can you give any more info about the crash (as reported by Windows)?
I can't reproduce the crash with my build, either. Using libexif 0.6.16 built from source.
I forgot to mention: my Gimp 2.6.0 installer also ships with libexif 0.6.16 built from source.
It looks like this can't be reproduced. Howard, perhaps you can provide more information that could help to find out what's different on your system?
OK, this is a hard bug to reproduce. I finally did it however. Below is the data from trapping this in the Visual Studio debugger. It seems that this ONLY happens when something is not cached (in the OS?). I can open the same file a second time without problems. I can not get to re-occur until some time (days?) have passed since I used GIMP. Without symbols for libglib-2.0-0.dll I cannot get any further in tracing this back (but I'm willing to try). Sorry, but it looks like too much work for me to attempt my own rebuild of GIMP. _strlen: 77C478A0 mov ecx,dword ptr [esp+4] 77C478A4 test ecx,3 77C478AA je _strlen+20h (77C478C0h) 77C478AC mov al,byte ptr [ecx] 77C478AE inc ecx 77C478AF test al,al 77C478B1 je _strlen+53h (77C478F3h) 77C478B3 test ecx,3 77C478B9 jne _strlen+0Ch (77C478ACh) 77C478BB add eax,0 77C478C0 mov eax,dword ptr [ecx] <======CRASH POINT 77C478C2 mov edx,7EFEFEFFh 77C478C7 add edx,eax 77C478C9 xor eax,0FFFFFFFFh 77C478CC xor eax,edx 77C478CE add ecx,4 77C478D1 test eax,81010100h 77C478D6 je _strlen+20h (77C478C0h) 77C478D8 mov eax,dword ptr [ecx-4] 77C478DB test al,al 77C478DD je _strlen+71h (77C47911h) 77C478DF test ah,ah 77C478E1 je _strlen+67h (77C47907h) 77C478E3 test eax,0FF0000h 77C478E8 je _strlen+5Dh (77C478FDh) Registers at crash: EAX = 00000000 EBX = 00000000 ECX = 00000000 EDX = 00000000 ESI = 00000000 EDI = 00000000 EIP = 77C478C0 ESP = 0022F08C EBP = 0022F408 EFL = 00000246 Call stack: > msvcrt.dll!_strlen() + 0x20 bytes libglib-2.0-0.dll!6861dc13() [Frames below may be incorrect and/or missing, no symbols loaded for libglib-2.0-0.dll] libglib-2.0-0.dll!6861d830() ntdll.dll!_RtlFreeHeap@12() + 0x130 bytes ntdll.dll!_RtlFreeHeap@12() + 0x114 bytes Where libglib module loaded: libglib-2.0-0.dll C:\Program Files\GIMP-2.0\bin\libglib-2.0-0.dll N/A N/A Binary was not built with debug information. 6 2.18.1.0 10/1/2008 9:33 AM 685C0000-68696000 [3472] gimp-2.6.exe: Native Libglib disassembly: 6861DBD8 sub eax,9 6861DBDB cmp eax,2 6861DBDE sbb ecx,ecx 6861DBE0 and ecx,13h 6861DBE3 add ecx,15h 6861DBE6 mov dword ptr [ebp-31Ch],ecx 6861DBEC jmp 6861DAD0 6861DBF1 cmp dword ptr [ebp-318h],12h 6861DBF8 je 6861E3DC 6861DBFE mov eax,dword ptr [ebp-2ECh] 6861DC04 lea edx,[esi+esi*2] 6861DC07 mov eax,dword ptr [eax+edx*8+8] 6861DC0B mov dword ptr [esp],eax 6861DC0E call 6863A1F8 <==== the call that crashed 6861DC13 mov dword ptr [ebp-31Ch],eax 6861DC19 jmp 6861DAD0 6861DC1E mov esi,0Bh 6861DC23 mov dword ptr [ebp-31Ch],esi 6861DC29 jmp 6861DAD0 6861DC2E mov eax,dword ptr [ebp-318h] 6861DC34 sub eax,9 6861DC37 cmp eax,2 6861DC3A sbb eax,eax
Sorry but that doesn't really say much. We need a stack trace from a version of GIMP with debugging symbols.
Thanks to Jernej Simončič .... here it is- a gdb backtrace. I installed his 2.6.1 debug build. As per his suggestion, I also downloaded and installed gtk+-bundle_2.14.3-20081006_win32.zip Program received signal SIGSEGV, Segmentation fault. 0x77c478c0 in strlen () from C:\WINDOWS\system32\msvcrt.dll (gdb) backtrace
+ Trace 208243
That looks like a "valid" crash that should be fixed. Since it only appears to occur on Windows though we will need help with debugging this crash. A patch for it would of course be very nice as well.
As an aside, I *think* this error only occurs if there is no preview for a picture and I try opening before a preview is computed. It doesn't always fail but, if I pick a largish file with no preview, it almost always crashes if I double click without waiting for the preview to complete/display. I wonder if this is a race condition between threads. I guess I'll have to bite the bullet and try building GIMP from source so I can trace deeper....
*** Bug 556866 has been marked as a duplicate of this bug. ***
I had a look at the code, but I don't see anything wrong. The plug-in keeps a reference on the progress object (via GimpPlugInProcFrame). So the progress should still be valid when the plug-in call that creates the preview returns.
I found a way to reproduce the problem in a more reliable way. Open a PDF file from the File->Open menu. Then, with the PDF import dialog opened, close the application. This results in a warning. When started in a debugger with --g-fatal-warnings the resulting stack trace is very similar to the one from comment #12. There seems to be an additional problem with g_log() on Windows. The actual crash happens in the code that should just print a warning to stdout. We have had several reports now about crashes on Windows where the code on Linux just outputs a warning and continues.
Should be fixed by this commit: 2008-10-21 Michael Natterer <mitch@gimp.org> Bug 555246 – gimp crashes when a file is opened while a preview is generating * app/widgets/gimpfiledialog.c: set dialog->progress to NULL in destroy() and check for progress being NULL in various places so we don't crash on API calls after the widget is destroyed. I have now also merged this to the stable branch.
Looking at it again, this does not fix this bug, but only the related problem I outlined in comment #17. GimpThumbBox needs a similar change.
2008-10-22 Sven Neumann <sven@gimp.org> Merged from trunk: Bug 555246 – gimp crashes when a file is opened while a preview is generating * app/widgets/gimpthumbbox.c: set box->progress to NULL in destroy() and check for progress being NULL in various places so we don't crash on API calls after the widget is destroyed.
*** Bug 560697 has been marked as a duplicate of this bug. ***
*** Bug 558170 has been marked as a duplicate of this bug. ***