GNOME Bugzilla – Bug 351246
dragging brush past edge of scrolling window with wacom tablet causes crash
Last modified: 2008-01-15 13:10:46 UTC
Steps to reproduce: 1. Create a new image, then resize the drawing window to be smaller than the image. 2. Start painting in the center of the window, then holding down the pen, drag the pen past the lower-right corner of the image. (as you normally would to get gimp to auto-scroll down to the lower-right corner of the image) 3. The Gimp segfaults. Stack trace: [Switching to Thread -1218639424 (LWP 5450)] gimp_display_shell_canvas_tool_events (canvas=0x869cbf0, event=0x8d8d160, shell=0x83762a0) at /build/buildd/gimp-2.2.12/./app/display/gimpdisplayshell-callbacks.c:1070 1070 /build/buildd/gimp-2.2.12/./app/display/gimpdisplayshell-callbacks.c: No such file or directory. in /build/buildd/gimp-2.2.12/./app/display/gimpdisplayshell-callbacks.c (gdb) Hangup detected on fd 0 Error detected on fd 0 error detected on stdin The program is running. Exit anyway? (y or n) (script-fu:5453): LibGimpBase-WARNING **: script-fu: wire_read(): error Other information: It seems to crash just when it is supposed to auto-scroll to the part of the image not visible through the small window. OS is Debian GNU/Linux (same crash with both Testing and Unstable debian). Tablet is Wacom Grapphire3 USB. It doesn't crash when I do the same thing with my mouse. On the same system, on Windows, I don't get this crash.
I tried building the gimp from the latest sources from CVS. (It reads 2.3.11 in the about box). The crash doesn't occur.
I have looked through the ChangeLog and did some Bugzilla queries but I didn't find any hint on what could have fixed this. Looking at the GIMP 2.2 sources also didn't show me an obvious bug. I will set the milestone for this to 2.2, perhaps someone wants to try to fix it. But we would better concentrate on getting out GIMP 2.4.
Thanks for taking a look. I did find one other report of this same problem, on the debain mailing list: http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/90a907292d52a92d/713fdf1c35a4bea8 It's not just the debian package though, as I tried building from the 2.2.12 soures and still get the crash. Oh well, I'm happy to use the 2.3 CVS version :)
I have this problem on gimp 2.2.10, but not on gimp 2.3.7. Here is some gdb log, if some developer wants an interactive debug session we could arrange an irc meeting, at least in order to backport the fix (I am constrained to use the unstable version to work right now): (gdb) r Starting program: /opt/gnome/bin/gimp [Thread debugging using libthread_db enabled] [New Thread -1219057360 (LWP 5730)] Program received signal SIGSEGV, Segmentation fault.
+ Trace 71568
Thread NaN (LWP 5730)
similar Ubuntu bug https://launchpad.net/products/gimp/+bug/57676
Unfortunately I must say it happens with 2.3.12 too. (Gtk 2.8.17, xorg 7.1 and linuxwacom 0.7.4)
> Unfortunately I must say it happens with 2.3.12 too. Yes, me too.
I bought a wacom grapphire4 usb today and gimp crashed on me. looked for it and after some 0 minutes, voilá: this bug reflects exactly what's happening with me. versioning info: linuxwacom 0.7.4 gtk+ 2.8.20 gimp 2.3.12 further info necessary? Willing to help :)
(In reply to comment #8) I've confirmed that the crash happens both in relative and absolute mode. I've also tried compiling gimp with debug info but still couldn't get a stack trace (with gdb), possibly before most supporting libs are NOT compiled with debug info.
On some distros, you can install the debug versions for the libs from the package repository.
Is there any easy way to get a list of what debug packages to install, or is it trial and error (on Ubuntu here, which does have that kind of packages).
libgtk2.0-0-dbg is all you should need to get a useful stack trace.
stoffe@homer:~$ gimp-2.3 This is a development version of GIMP. Debug messages may appear here. gimp-2.3: fatal error: Segmentation fault gimp-2.3 (pid:10890): [E]xit, [H]alt, show [S]tack trace or [P]roceed: s
+ Trace 88836
Gimp 2.2 also segfaults but gives no additional messages whatsoever. Running both under gdb none of them crashes at all... Guess that isn't too helpful, is there anything more I could do?
I get the same problem mentioned above. But I have a suggestion or more of a request for a work around. Could we get someway to turn off this whole "feature" where the screen scrolls when the drawing cursor reaches an edge? I hated that even before I encountered this bug. I'd be drawing or painting along, touch the bottom of the screen for a moment and bam, I'd have a brush stroke going all the way from where it intersected the bottom of the drawing window to the actual bottom of the picture. I'd much prefer to just loose a few pixels by not having the cursor draw anything than have to erase this line and repair anything under it. This was a usability bug before it became a critical one. How often do you suppose this feature is "used" vs "suffered" even when it doesn't result in a crash? Having the screen rapidly move some arbitrary distance with the drawing tool down and drawing, who came up with that? There ought to be a setup item, config file entry, or command line option to turn this thing off, even if you fix the bug. If there is one please tell me about it.
Autoscroll is very useful. If it doesn't work correctly for you, then the implementation should be fixed. Adding more config options should be avoided by all means.
Sorry to use the word hate for a feature you're proud of, but for people who draw or paint with the gimp (not it's main feature I know) I think this can be a real annoyance, but not killer bug (well minus the crash, not a killer bug) Auto scroll for drag and drop, for moving a floating selection etc == all win and good. I just think it's a bad default action for freehand drawing tools, where bam, you get a line drawn all the way accross the screen. I have to stop, undo the drawing I just did hope it wasn't a full minute of trying to paint the edge of something or sketching a difficult body part in a wierd pose I just finally got right. Then pull my heart out of my throat if it's been an hour since my last save and the screen just scrolled 700 pixels down in half a second for no apparent reason. Just my opinion. Any how further checking shows that the Gimp can successfully track the Wacom tool past the window boundries as long as it doesn't try to scroll the window at the same time. The freehand select doesn't scroll the window and it works fine, the rectangle and elipse select tools crash when the bounding box is dragged beyond the window same as the paint tools do. Similarly dragging the cursor out of the window with the tablet doesn't crash when using Transform tools or the gradient tool. When Paint tool cursor and brush outline are disabled and trying to draw on a layer smaller than the canvas (so the GIMP has nothing to draw, not even a cursor) it still crashes when the invisible cursor reaches the edge of the window and the Gimp scrolls the window to follow it. Did a complete system update between first post and this. Now Debian testing, with Kernel 2.6.18-3 including the latest stable Wacom drivers all around (much pain getting mouse back) and latest 2.2.13 Gimp and Gnome 2.14.3 with none of the new 3D eye candy turned on. Went back to Gnu nv drivers from the nvidia proprietary ones. No difference.
Disabling auto-scroll for paint tools is as simple as adding the line gimp_tool_control_set_scroll_lock (tool->control, TRUE); to gimp_paint_tool_init() in app/tools/gimppainttool.c, Perhaps we should consider to do this change. Do we need to make this optional?
After a quick poll on the gimp-user mailing-list, I have now done this change in the HEAD branch: 2006-12-03 Sven Neumann <sven@gimp.org> * app/tools/gimppainttool.c (gimp_paint_tool_init): don't autoscroll with paint tools.
Confirmed that this happens on Debian Unstable with Gimp 2.2.13 -Dom
The bug doesn't occur anymore with Gimp-2.3.13 with painting-tools, but when using other tools like "Moving", and moving the layer out of window gimp still crashes. But maybe this is a situation where we could need the scrolling-feature (but i could live without this feature with tablet-painting too).
I also get this crash on Mandriva 2007 with GIMP 2.3.12: http://qa.mandriva.com/show_bug.cgi?id=24781
I tried to reproduce this and pulled my old serial Wacom tablet out of the dust. But everything seems to work just fine. I really don't know what else we can do.
I have gimp version 2.2.13 from ubuntu feisty, and the bug is there, perfectly and deterministically reproducible. I just installed gimp dbgsym packages, and got a different backtrace it seems. I declare myself even available for an interactive debug session on IRC/IM if you like, if I can help to solve this outstanding, and grave bug. == BACKTRACE ==
+ Trace 114128
Looks like the same backtrace to me. And I don't see anything wrong in that part of the code. It looks like we are getting bogus events from the underlying layers and I don't see how we could work around that. In my opinion this bug is located in either GDK or the wacom driver and needs to be fixed there.
Indeed, it is! I don't understand in which way my eyes skipped lines so that I found them different. Sven: what should we do? I am still available for debug but I don't know exactly how to do this myself - so perhaps I am not the right person at all.
First thing to do would be to try and isolate it a bit further. Getting the versions of the drivers, GDK, etc that it could be from the affected distros, as it seems it is several. I'm not sure what the relevant numbers are here or how to find them, at least for GDK under Ubuntu 6.10. Wacom driver seems to be 0.7.2 which is on the oldish side I think. Maybe try out newer or even development versions of GDK and the Wacom driver and see if that helps, and if needed ask distros to update to newer versions if that fixes it. Or maybe someone good at stuff like this could simply track down these "bogus events". I can repeat this reliably for any stable or development version of GIMP I have access to, but it doesn't affect any other application at all. So naturally, GIMP will look like the bad guy here, no matter if that is true or not - and it's for several popular distros. Would be nice for both the users and GIMP to get this fixed somehow.
I have tested this on Ubuntu and can't reproduce the problem. It not only seems to be specific to the version of the wacom driver but also to the tablet model. So if anyone wants to try to isolate the problem, please do also collect information about the tablet being used.
Wacom Graphire 4 USB Tablet. Wacom-tools version: 1:0.7.2-0ubuntu7
Kristoffer, could you update your wacom drivers to 0.7.4 and test if that fixes the problem? You can probably use the drivers from the Debian repository.
Installed wacom-tools_0.7.4.1-5_i386.deb and xserver-xorg-input-wacom_0.7.4.1-5_i386.deb from Debian testing, tried both restart of X and restart of computer, but alas, it's still the same.
Tablet: Wacom Intuos 3 USB System: debian unstable dpkg -l ii wacom-tools 0.7.4.1-6 ii xserver-xorg-input-wacom 0.7.4.1-6 ii gimp 2.2.13-1 ii gdk-imlib1 1.9.14-32 ii gdk-imlib11 1.9.14-32 ii libgdk-pixbuf-gnome2 0.22.0-11 ii libgdk-pixbuf2 0.22.0-11 Sorry, no dev version of gimp or the driver yet Werner
Seems it is the Wacom driver, see https://sourceforge.net/forum/message.php?msg_id=4217496 Quoting myself: "0.7.6-4 (the latest I found on downloads) seems to fix this. I just copied the prebuilt wacom_drv.so to /usr/lib/xorg/modules/input/ (which apparently is a bad bad idea to do while X is running :D) and now Gimp stable as well as dev works without crashing, at least for a few quick tests. This is on Ubuntu 6.10, Graphire 4 with Kernel 2.6.17 and Xorg 7.1.1 for reference." Would be very nice if more could confirm this, as I've only made a few quick tests so far.
I _tried_ to compile linuxwacom 0.7.6-4 by myself and the copying over the default in debian (see my previous post for my system data). If the following is the correct message after insmod of the compiled module i still get the error in with version 0.7.6-4. ====================== cat /var/log/messages ... kernel: .../linuxwacom-0.7.6-4/src/2.6.16/wacom_sys.c: v1.46:USB Wacom Graphire and Wacom Intuos tablet driver ... ====================== If that message is bad (as the howto [1] hints to) what can i do to get the correct module to load? It the original wacom.ko module is not reachable for the kernel (i moved it out of the way), only the compiled one - and the tablet works (except for the topic-problem unfortunately) Werner [1] http://linuxwacom.sourceforge.net/index.php/howto/testwacom
Did you try the prebuilt version that is already compiled? That's the one that worked for me (knock on wood).
I did not use the precompiled stuff, but I didn't copy the self-compiled wacom_drv.so to the /usr/lib/xorg/modules/input directory [1]. The same setup (gimp 2.2.13, debian unstable 2.6.17-1-k7) as I mentioned above now seems to work with the 0.7.6-4 version of linuxwacom. Touching hte image border in any zoom works like expected (though the auto-panning is really annoying as already discussed earlier :)) Thanks for all your help and for this great app+driver, Werner [1] I only copied the wacom.ko to /lib/modules/2.6.17-1-k7/kernel/drivers/usb/input - could not find any other instruction that would mention the .so file ... I may have missed that bit in the howto :)
So is this NOTGNOME? Maybe someone else can try the same and report back?
Ok, all evidence does point to linuxwacom, and there are reports that 0.7.6 does fix this. Closing as NOTGNOME.
*** Bug 358442 has been marked as a duplicate of this bug. ***
*** Bug 450408 has been marked as a duplicate of this bug. ***