After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 152151 - BadWindow error during drag and drop
BadWindow error during drag and drop
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Backend: X11
2.4.x
Other Linux
: Normal normal
: Medium fix
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2004-09-08 10:53 UTC by Thomas Leonard
Modified: 2014-03-24 03:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Another backtrace (4.81 KB, text/plain)
2005-03-14 12:50 UTC, Thomas Leonard
Details
backtrace for gnome dnd bug (1.27 KB, text/plain)
2005-03-28 12:16 UTC, Kacper Wysocki
Details

Description Thomas Leonard 2004-09-08 10:53:37 UTC
Bug report from a user:

"I've upgraded to GTK 2.4.7, [...] but i'm still getting crashes.
Usually when i go to drag a file/folder to another window, but i can't reliably
reproduce it.
Using Filer  2.1.3 from /uri/0install/rox.sourceforge.net/testing/"

We've managed to get a stacktrace:

  • #0 ??
  • #1 raise
    from /lib/tls/libc.so.6
  • #2 abort
    from /lib/tls/libc.so.6
  • #3 rox_x_error
    at /home/snapshot/ecs.soton.ac.uk/site/ROX-Filer/src/main.c line 215
  • #4 _XError
    from /usr/X11R6/lib/libX11.so.6
  • #5 _XReply
    from /usr/X11R6/lib/libX11.so.6
  • #6 _gdk_x11_get_window_child_info
    at gdkasync.c line 697
  • #7 gdk_window_cache_new
    at gdkdnd-x11.c line 493
  • #8 drag_context_find_window_cache
    at gdkdnd-x11.c line 3085
  • #9 gdk_drag_find_window_for_screen
    at gdkdnd-x11.c line 3128
  • #10 gtk_drag_update_idle
    at gtkdnd.c line 3233
  • #11 g_child_watch_add
    from /usr/lib/libglib-2.0.so.0
  • #12 g_main_depth
    from /usr/lib/libglib-2.0.so.0
  • #13 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #14 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #15 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #16 gtk_main
    at gtkmain.c line 1173
  • #17 main
    at /home/snapshot/ecs.soton.ac.uk/site/ROX-Filer/src/main.c line 575

rox_x_error is set in main() as the toplevel error handler. It replaces GDK's
default handler with one that calls abort() instead of exit().

The comments suggest that _XReply is expected to call a special error handler,
but is actually calling the default one.

The discussion is here, and includes the output from 'bt full' in the 8 sep post:

http://thread.gmane.org/gmane.comp.desktop.rox.devel/5435
Comment 1 Matthias Clasen 2004-09-08 14:01:05 UTC
Hmm, the question is: how can screen be NULL in frame 9
Comment 2 Thomas Leonard 2004-09-08 15:40:17 UTC
I guess that's just a compiler optimisation messing up the variables. The code
does several checked casts on screen before it gets to _XReply, so I don't think
it can have been NULL on entry.
Comment 3 Matthias Clasen 2004-09-11 04:27:23 UTC
Hmm, inside _gdk_x11_get_window_child_info() you can see that we do call
gdk_error_trap_push()/pop() around the call to list_children_and_wm_state(),
which in turn also uses the async GetResReq()/_XReply(), so we're inconsistent
here. Either error trapping is necessary, in which case we need it around the 
_XReply() in _gdk_x11_get_window_child_info() as well, or it is not, in which
case it it redundant around _gdk_x11_get_window_child_info().
Comment 4 Owen Taylor 2004-10-07 18:16:27 UTC
list_children_and_wm_state() doesn't push an async handler when 
wm_state_atom() is NULL, so the error trap is needed there.

One possibility is that the XError that is being received is something other 
than BadWindow/BadDrawable  get_child_info_handler() only ignores those.

Does your special error handler actually dump the error information? - that
would be very useful information to have.
Comment 5 Thomas Leonard 2004-10-08 09:10:46 UTC
The error message was "BadWindow (invalid Window parameter)", according to the
'bt full' output here:

http://article.gmane.org/gmane.comp.desktop.rox.devel/5645
Comment 6 Thomas Leonard 2005-03-14 12:50:42 UTC
Created attachment 38696 [details]
Another backtrace

Here another backtrace from a crash during a drag and drop operation, this time
seen on my own machine (using Debian's GTK 2.6.2-4).
Comment 7 Kacper Wysocki 2005-03-28 12:16:14 UTC
Created attachment 39333 [details]
backtrace for gnome dnd bug

Here's another backtrace with debian sid gtk 2.6.2-4 during a drag-n-drop
operation. This happens *often*, but is inpredictable enough that I don't know
precisely how to trigger it.
Comment 8 Matthias Clasen 2014-03-24 03:04:51 UTC
closing out ancient bugs