GNOME Bugzilla – Bug 707653
Crash on window resize in single-window mode
Last modified: 2016-05-13 00:37:29 UTC
Created attachment 254302 [details] Log from GIMP startup to crash when trying to move window Build: 2013-09-06 nightly OS: Win7 Enterprise SP1, 32-bit System: 4GB RAM; 60GB free hard drive space Steps: - self-extract the 2013-09-06 nightly from http://nightly.darkrefraction.com/gimp/stable/gimp-stable-i686-2013-09-06.exe into c:\program files - remove c:\users\<me>\.gimp-2.8 - At a command line, add C:\Program Files\gimp-stable-i686-2013-09-06\bin to the end of the PATH - In C:\Program Files\gimp-stable-i686-2013-09-06\bin, run gimp-2.8.exe --verbose >log.txt - Choose Windows | Single-Window mode (which appears to work fine) - Either: - Grab the title bar with the mouse and try to move the GIMP window. It moves a few pixels then crashes. or - Grab the right edge of the window with the mouse and try to resize. It moves a pixel or two then crashes. After the crash, gimprc has nothing in it but the header and footer comments. Log attached for the crash when moving, run as gimp --verbose --debug-handlers --stack-trace-mode=always -c > log2.txt The main window moves and resizes fine when not in single-window mode. (It locks up if I resize the toolbox too much, but that's a bug report for another day.)
Hello, Thanks for reporting the bug. I am not sure if gdb is available on Windows (but any other debugger would make the trick), but would it be possible to have a stack trace of the time of the crash please? Here is how to create stack traces with gdb: https://wiki.gnome.org/GettingTraces Basically you run GIMP with gdb, provoke the crash, then get a backtrace (bt) and copy it in a file. Also you are working with a development version of the gimp-2-8 branch. Does your crash also happens with the stable GIMP 2.8.6?
The crash does not happen with stable 2.8.6 - I switched to nightlies to get the fix for bug 703113. I reran the 9-6 nightly under Cygwin gdb. The wiki says paste the log rather than attaching, so here goes... $ export PATH=$PATH:/cygdrive/c/Program\ Files/gimp-stable-i686-2013-09-06/bin $ gdb gimp-2.8.exe GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special) Copyright (C) 2013 Free Software Foundation, Inc. <License block cut> This GDB was configured as "i686-pc-cygwin". <cut> Reading symbols from /cygdrive/c/Program Files/gimp-stable-i686-2013-09-06/bin/gimp-2.8.exe...done. (gdb) run Starting program: /cygdrive/c/Program Files/gimp-stable-i686-2013-09-06/bin/gimp-2.8.exe [New Thread 3648.0x1688] [New Thread 3648.0xab4] [New Thread 3648.0x1634] [New Thread 3648.0x13d0] [New Thread 3648.0x127c] [New Thread 3648.0xbdc] [New Thread 3648.0x92c] [New Thread 3648.0xad8] [New Thread 3648.0x6b8] [New Thread 3648.0x1078] Program received signal SIGSEGV, Segmentation fault. 0x00df9a80 in sse2_blt () from /cygdrive/c/Program Files/gimp-stable-i686-2013-09-06/bin/libpixman-1-0.dll (gdb) bt
+ Trace 232460
Thread 1 (Thread 3648.0x1688)
A debugging session is active. Inferior 1 [process 3648] will be killed. Quit anyway? (y or n) (script-fu.exe:2888): LibGimpBase-WARNING **: script-fu.exe: gimp_wire_read(): error
Thanks, that will be useful. I tried to reproduce with Windows 7 in a VM but couldn't with master. I have no gimp-2-8 cross-compiled for Windows right now. I will try later. 2 questions: 1/ In your reproduction steps, are the 2 steps "removal of c:\users\<me>\.gimp-2.8" and modification of the PATH necessary for the crash to happen for you? If they are, that may be a lead to understand the problem. If they are not necessary for the crash to happen (that is, it crashes even if you keep your existing .gimp-2.8/ configuration directory and the current PATH), please tell us, so that we don't waste time on searching in this direction. 2/ Have you tried with gimp master as well (what they call "Development Series (2.9)" in the http://nightly.darkrefraction.com/gimp web page, and does GIMP crash as well with this version? Thank you very much.
Thanks very much for looking into this! 1. I re-ran with my existing .gimp-2.8, which has some additional plugins beyond stock (e.g., ani.exe). I ran from the command line, and gimp...\bin was not in the path. The crash still happened. The splash screen came up, then I had to click through lots of messages that "The program can't start because libgimpui-2.0-0.dll is missing from your computer. Try reinstalling the program to fix this problem." Once I did so, Gimp came up in single-window mode (per .gimp-2.8\sessionrc "(single-window-mode yes)"). Gimp was maximized since that's how I left it last time. I restored by clicking the button in the title bar, which worked. I then grabbed the top border with the mouse and started to drag and got the crash. Let me know if you would like a trace. 2. I do get the crash with http://nightly.darkrefraction.com/gimp/dev/gimp-dev-i686-2013-09-09.exe. Same steps to reproduce as in comment 1. Trace from cygwin gdb, same version as in comment 1, no ~/.gimp-2.9, gimp.../bin in PATH: Reading symbols from /cygdrive/c/Program Files/gimp-dev-i686-2013-09-09/bin/gimp-2.9.exe...done. (gdb) run Starting program: /cygdrive/c/Program Files/gimp-dev-i686-2013-09-09/bin/gimp-2.9.exe [New Thread 3560.0x14a8] [New Thread 3560.0x8b0] [New Thread 3560.0x1554] [New Thread 3560.0x1304] [Thread 3560.0x1304 exited with code 0] [Thread 3560.0x1554 exited with code 0] This is a development version of GIMP. Debug messages may appear here. [New Thread 3560.0x490] [New Thread 3560.0x1210] [New Thread 3560.0xf30] [New Thread 3560.0x16a8] [New Thread 3560.0xafc] [New Thread 3560.0xff8] [New Thread 3560.0xef8] [Thread 3560.0x1210 exited with code 0] Program received signal SIGSEGV, Segmentation fault. 0x00f89a80 in sse2_blt () from /cygdrive/c/Program Files/gimp-dev-i686-2013-09-09/bin/libpixman-1-0.dll (gdb) bt
+ Trace 232463
Thread 1 (Thread 3560.0x14a8)
Thread 1 (Thread 5632.0x364)
Hi, ok I will try to reproduce it again. Basically to sum-up, you get the crash when you try to resize or move the window in single-window mode, whatever you do else, right? Since I am one of the rare GIMP developers who sometimes fix GIMP on Windows, I'll assign this bug to myself and will have a look when I make some time for it. Don't expect necessarily a fix in the next few days though. That depends on my moods ;-).
Your summary is correct. For example, in stable-09-09, I just successfully created an image, made rectangular selections and filled them, created layers, and toggled layer visibility, all in single-window mode. After that I tried to resize the left edge of the GIMP window with the mouse and immediately got the crash. I understand the timing is entirely up to you and appreciate your taking this on! (PS - comment 4, trace 232463, includes two traces, one of dev-09-09 and one of stable-09-09. I didn't know Bugzilla would grab both in one trace. Both crashed under the same circumstances.)
Hey, I've just tried to reproduce again, but definitely could not with last code, both for master and gimp-2-8 branch, at least that I compiled myself. I tried the nightly build binaries though. With them, I could reproduce definitive issue when moving/resizing, but not a crash. Basically it looks like the expose event won't work or something, and after a move/resize, the drawn window is a mess and won't redraw well (but if I use well-known shortcut, I can still see pieces of dialog boxes or stuff, so GIMP is still running behind the broken UI). So I say the problem is either: 1/ the way the nightly builds are made, maybe some particular compile option. I doubt it though because it looks like a core issue. I will ask anyway on the dev mailing list what options and library versions are used; 2/ a problem only showing up on the 32 bit Windows version. I have only built a 64 bit version. I will compile a 32 bit to test later, but not tonight. I am tired and will go to bed. :p 3/ a problem showing only on Windows 32 bit. I have only Windows 7 64-bit. So I will try and run GIMP 32-bit on Windows 64-bit. If the problem occurs with GIMP 32 on Windows 32-bit, well I won't be able to reproduce (and I certainly don't plan on buying another Windows license :p). But we'll see this later. 4/ Something else?
Ok so I recompiled in 32 bits. And it worked well! Then since I also had issues with the nightbuild, what I did to see if they came from GIMP or a dependency is that I copied all the bin/*gimp* I compiled myself over to the nightbuild bin/. And I still had problems there, even with my own GIMP. Then since the trace shows a problem on a call to cairo_fill, I copied over libcairo-2.dll from my tree to the nightbuild's (as well as libpng15-15.dll because nightbuild uses libpng16-16.dll). Well the crash disappears! (note: I tried afterwards with nightbuild's GIMP binary too, if you just add libpng15-15.dll and copy over libcairo-2.dll from an older one, the crash also disappears) I personally use cairo 1.10.2 and libpng 1.5.11 got from OpenSuse 12.1 packages (yeah they are kind of old). I guess the nightbuild uses libpng of the 1.6 series, and probably a higher version cairo (of the 1.12 series, because I had a warning about a missing cairo_mesh_pattern_begin_patch (), which exists since 1.12, even though we don't have this call in our codebase). I will enquire further. In short: GIMP is broken for Windows using Cairo over 1.10.2 (last release of the 1.10 series).
Well, I compiled cairo-1.12.14, first with libpng 1.5.11, then I tried with a self-compiled libpng-1.6.3 (I also compiled gdk-pixbuf 2.28 to use libpng16). Well works well here. I really don't know what is the problem with the nightbuild binaries. I'll ask on the mailing list what options exactly they use.
Ok so I have sent an email to the dev mailing list since I can't reproduce it with self-built binaries (only with the nightbuild dlls). I won't investigate further until I know if the problem is from faulty DLLs or if we can do something about it. Because as far as I could see, by using very recent cairo and png libraries, when I compile them myself, all works fine. So it looks like a NOTABUG from where I stand (though there is clearly a problem in the nightbuilds). So now I wait for answers from whoever builds these nightbuilds. :-)
Just for information, out of good conscience, I just downloaded and tested with cairo 1.12.16 too. So GIMP works well with old as well as the last released versions cairo and libpng. There is definitely something fishy in the DLLs embarked in the nighbuilds.
For confirmation, I tried the gimp-stable-i686-2013-09-10 nightly and had the same crash. I then copied libcairo-2.dll and libpng15-15.dll from the release of 2.8.6 (Jernej's Win32 installer) into ...09-10\bin and am now able to resize, minimize, and maximize in single-window mode with no problems. I also get the cairo_mesh_pattern_begin_patch message. Thanks for the workaround! I look forward to hearing the final resolution when darkrefraction gets back to you.
Hello. I'm the maintainer of the nightly builds. Could you try the latest build (Sept 12)? I updated pixman, which may have included a fix for this. If that does not work, I'd appreciate it if you downloaded one of the builds with debugging symbols (marked -dev) from here: http://nightly.darkrefraction.com/gimp/dev/ Please then get another stacktrace with "bt full", so it contains local variable information. Thanks!
stable-2013-09-12 crashes in the same way, under the same test conditions (no .gimp-2.8, ...\bin in PATH (started with run_gimp.bat). Dev-2013-09-12, run from cygwin gdb, no ~/.gimp-2.8, .../bin in PATH, does likewise. Trace below. In case it matters, the CPU is a Core2 Duo E7500 2.93GHz (x86 family 6, model 23). (PS - the first time I saw the GEGLized splashscreen, I thought I had somehow downloaded a trojan :) ) GNU gdb (GDB) 7.6.50.20130728-cvs (cygwin-special) <license info cut> This GDB was configured as "i686-pc-cygwin". <help cut> .. Reading symbols from /cygdrive/c/Program Files/gimp-dev-i686-2013-09-12/bin/gimp-2.9.exe...done. (gdb) run Starting program: /cygdrive/c/Program Files/gimp-dev-i686-2013-09-12/bin/gimp-2.9.exe [New Thread 5456.0x16a8] [New Thread 5456.0x1704] [New Thread 5456.0xf50] [New Thread 5456.0xa84] [Thread 5456.0xf50 exited with code 0] [Thread 5456.0xa84 exited with code 0] This is a development version of GIMP. Debug messages may appear here. [New Thread 5456.0x12b0] [New Thread 5456.0x300] [New Thread 5456.0x112c] [New Thread 5456.0x1290] [New Thread 5456.0x1288] [New Thread 5456.0x1360] Program received signal SIGSEGV, Segmentation fault. 0x00f89a80 in sse2_blt () from /cygdrive/c/Program Files/gimp-dev-i686-2013-09-12/bin/libpixman-1-0.dll (gdb) bt full
+ Trace 232480
Thread 1 (Thread 5456.0x16a8)
(gdb) quit A debugging session is active. Inferior 1 [process 5456] will be killed. Quit anyway? (y or n) (script-fu.exe:2692): LibGimpBase-WARNING **: script-fu.exe: gimp_wire_read(): error
Re the "No symbol table info available" messages - I made sure I was on the latest gdb and cygwin1.dll, ran gdb, tried loading referenced dll symbols with dll-symbols, and ran. E.g., for libcairo-2.dll, after the segv, "info dll" in gdb shows that the symbols were loaded, but "bt full" still says "No symbol table info available." I can't find any quick fixes on stackoverflow or forums - looks like there's lots of different reasons. If you have any thoughts as to what else I could try to get a better trace, please let me know.
If you go to the link I gave you: http://nightly.darkrefraction.com/gimp/dev/ Please download the latest build with "-dbg" in the name (near the bottom). Those have debugging symbols; the normal ones do not. As for the splashscreen: Yes, we often have some fun with that for the development versions :)
Created attachment 254868 [details] GDB trace of gimp-dev-dbg-i686-2013-09-12
I put the trace in an attachment because it's 213KB when uncompressed, and Bugzilla wouldn't let me paste more than 64K in. If you would prefer the log in a different format or presentation, please let me know. Thanks!
Created attachment 254870 [details] config log for cairo 1.12.16 cross-compiled for Windows 32-bit As asked on IRC by drawoc, attached my config.log for my own compilation of cairo 1.12.16. I know you told me on the ml that you used 1.12.14. I also had first a cairo 1.12.14 compiled, but I removed it after changing it for the latter 1.12.16. So I don't have the config log for 1.12.14. I could also fix the issue with my DLLs of 1.12.14 though. So that should not be a version issue here.
Sorry, typo. I am actually using cairo 1.12.16, like you.
It could be a bug in pixman for windows: https://bugs.freedesktop.org/show_bug.cgi?id=68300 It is interesting to see if disabling sse2 in pixman fixes the issue: https://bugzilla.redhat.com/show_bug.cgi?id=995059#c4
Okay, I've made a special build with sse2 disabled. You can download it here: (while supplies last!) http://nightly.darkrefraction.com/gimp/dev/gimp-dev-i686-2013-09-16-no-sse2.exe
(In reply to comment #22) > Okay, I've made a special build with sse2 disabled. > > You can download it here: (while supplies last!) > http://nightly.darkrefraction.com/gimp/dev/gimp-dev-i686-2013-09-16-no-sse2.exe Thank you, Mike, I downloaded and used the pixman dll to test the stable version, and on my Windows XP SP2 I'm no longer able to reproduce the crash. I've now attached a patch to: https://bugs.freedesktop.org/show_bug.cgi?id=68300 that should fix the issue, it seems to be a matter of stack alignment
Interesting. Maybe this is also the cause for UFRaw 0.18's crashes on Windows platforms.
I also cannot reproduce the crash on my system. :) I believe this is resolved, but I'm not updating the bug status because I don't know which resolution code is appropriate. Will future nightlies (especially stable) be no-sse2 until a release that includes the fixed pixman from upstream?
Okay, I've disabled sse2 on all my nightly builds starting with the ones for 2013-09-18 (these are the ones for tomorrow, so they aren't up yet). I'm marking this as resolved. If the 2013-09-18 build is not fixed, feel free to reopen this. I'll monitor the upstream bug and reenable sse2 when it's safe to do so. commit b2bbb1a8a7fe60e4e790dad82cb63a2b3cc81181 Author: Michael Henning <drawoc@darkrefraction.com> Date: Tue Sep 17 16:18:46 2013 -0400 build/win: Disable sse2 in pixman (Bug 707653)