GNOME Bugzilla – Bug 126212
screenshot plugin crashes on large captures
Last modified: 2014-03-24 03:11:51 UTC
Capturing small[1] windows seems to work find, but capturing large images[2] crashes the plugin, and the following message pops up: --------------------------------------- Plug-In crashed: "screenshot" (/home/lwillis/garnome-0.26.2/lib/gimp/1.3/plug-ins/screenshot) The dying Plug-In may have messed up GIMP's internal state. You may want to save your images and restart GIMP to be on the safe side. ---------------------------------------- I can't see how to get a backtrace though (If anyone can point me in the right direction I'll be happy to provide since I can reproduce this consistently). As you can probably tell this is built under garnome-0.26.2. Version 1.3.21 worked fine. [1] Rhythmbox in "small mode" (Approx 705x138 pixels) works fine [2] Epiphany at around 1280x980 crashes the plugin, as does a GNOME terminal at (Approx) 1024x768
I cannot reproduce this problem. Windows up to the size of my screen (1400x1050) are properly grabbed. To get a stack trace from the crashing plug-in, you can run gdb on the screenshot plug-in and attach to the plug-in process when the dialog is up. Type 'c' at the gdb prompt to let the plug-in continue. Then, when it crashed, type 'bt' to get a stack-trace.
Backtrace is less than useful :( (gdb) bt
+ Trace 41466
I'm assuming I need to re-compile something with -ggdb, but any suggestions of what? GTK? (Re-compiling everything will take a while on my lowly PIII .... and just re-compiling the screenshot plugin didn't help - I'm currently re-compiling the whole of GIMP with -g3 -ggdb) Any suggestions and I'll go and re-build ...
That actually looks quite useful already. You could install a package of gtk+ with debugging information enabled. The crash seems to happen in gdk-pixbuf which is part of gtk+. What your stack trace unveils is that the problem could be located in the conversion routines in gdk-pixbuf that are used when the X server is not running in true color mode. This would also explain why the problem doesn't appear on my system.
------- That actually looks quite useful already. You could install a package of gtk+ with debugging information enabled. The crash seems to happen in gdk-pixbuf which is part of gtk+. ------- OK - I'm re-building GTK now. ------- What your stack trace unveils is that the problem could be located in the conversion routines in gdk-pixbuf that are used when the X server is not running in true color mode. This would also explain why the problem doesn't appear on my system. ------- Ah - then maybe my initial bug report was misleading. What I didn't consider was that I recently changed monitor, and re-configured X, so maybe this bug just didn't show in previous version of GIMP because of my X setup. I'll try and confirm that either way as well ....
Created attachment 21213 [details] [review] patch that might fix the problem
I would appreciate if you could apply the patch I just attached and test if it cures the problem. I'm only guessing here but I found the clipping code rather confusing. I've rewritten it in a way that is easier to understand and thus more likely to be correct.
I've tried your patch, and unfortunately still get the same result :( The problem definitely occurs within gdk_pixbuf_get_from_drawable although at first glance we're passing sane arguments (NULL,0x80f2c00,NULL,0,0,0,0,1280,942). I've yet to get a decent backtrace though, or have chance to try moving to truecolour and seeing if that helps. I'll update later ...
It's almost certainly a GDK bug then. I will apply the patch anyway since it makes the code more easier to understand. Removing the PATCH keyword since the patch doesn't fix the reported problem.
Hmmm - switching to 24bpp from 16bpp stops the crash occuring. I'll move this from being a GIMP bug - sorry for any confusion - and thanks for the help ...
gdk_pixbuf_get_from_drawable() is a GDK function, not part of gdk-pixbuf. Changing the component accordingly. This bug was originally reported against GIMP-1.3.22.
Created attachment 21287 [details] test program
I couldn't reproduce this with the attached test program, running against X servers of various depths. Can you ?
Yes. Backtrace: bt
+ Trace 41604
The values for x1 and y1 above seem to be completely screwy, for reference I called the program as follows: $ ./testbug 0x1600008 1002 776 Where the values are all taken from xwininfo ...
In case it helps I've added various debug statements and attached the output. It should be fairly obvious where the debug's lie in the code. Maybe this will help?
Created attachment 21326 [details] Debug output
Can you run the test under ElectricFence? gdb testprog (gdb) set env LD_PRELOAD=/usr/lib/libefence.so (gdb) r <watch it segfault> (gdb) bt I can't see any problem staring at the code or in your debugging output. The obviously unusual thing about your configuration is using 555 rather than 565 - nobody really does that any more - but I don't see any obvious code portions where that would make a difference, and it's good that someone is testing the 555 code :-) Please reopen from NEEDINFO when you add more information.
Hmm - the only additional output I seem to get is the following line: 614 register guint32 data = *s++; (gdb) bt
+ Trace 41713
Does that help?
Owen, the earlier backtraces further up show the same crash happening in rgb565lsb, so it is not 555-specific.
lwillis, did you use any special flags when you compiled gtk+? Apparently noone else than you can reproduce this bug.
Well - the bug still occurs with gimp 2.0pre2 compiled against garnome 0.29.1. As far as I can see, the compile flags are: -g -O2 -pipe so fairly standard ... Is there anything else I can do to help debug?
Hmm, to me it looks the stack gets overwritten (broken trace, insane parameters). Some things that might be helpful: - either see if the bug occurs when you run remotely on the X server that usually causes the crash, or recompile gdk with --disable-shm - What happens when you run valgrind --num-callers=12 testprogram - recompile gdk without optimization and regenerate the backtrace but it's all pretty much random guesses from me. Other guesses would certainly be appreciated.
*** Bug 117487 has been marked as a duplicate of this bug. ***
The duplicate isn't very interesting, btw. Same reporter, same crash in the 565 code, different program.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
lwillis, did you try any of the proposals by Soeren ?
Sorry for the delays, I've installed valgrind, and attached the valgrind output.
Created attachment 30938 [details] Valgrind output of valgrind --num-callers=12 ./testprogram 0x1e0000a 1006 779
Could the problem be unaligned accesses ? rgb565lsb (and many of the other 16bit functions) seems to cast a guint8* to a guint16* and dereference the result....
closing out old bugs