GNOME Bugzilla – Bug 478243
Xlib: unexpected async reply
Last modified: 2008-07-09 22:15:41 UTC
Steps to reproduce: 1. Not easily by a recipe. (Sorry.) 2. But quite regularly. If I browse around in my library long enough, it will crash. It seems to be more frequent (or at least there's a higher probability of triggering it) when I'm pressing a right/left arrow key quickly to move through a bunch of photos in Browse mode, Stack trace: Other information: The app dies with a message of this sort: Xlib: unexpected async reply (sequence 0x21986)! The number after the sequence is variable. This bug has been noted before: https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/47807 (and that bug report includes stack traces) The finger is pointed there at: http://www.mono-project.com/FAQ:_Gtk#My_application_crashes_with_threads And, here, too: https://bugs.launchpad.net/ubuntu/+source/f-spot/+bug/63379 Those and other reports can be found: http://www.google.com/search?q=f-spot+xlib+unexpected+async+reply I had had about five crashes in twenty minutes before I started this bug report. I've attached gdb per the instructions here: https://wiki.ubuntu.com/Backtrace and it is stopping frequently with messages such as these: Program received signal SIGPWR, Power fail/restart. [Switching to Thread -1281168496 (LWP 16635)] 0x0806877e in ?? () (gdb) Continuing. Program received signal SIGXCPU, CPU time limit exceeded. [Switching to Thread -1280115824 (LWP 16634)] 0xffffe410 in __kernel_vsyscall () (gdb) Continuing. Program received signal SIGSEGV, Segmentation fault. 0xaf815737 in ?? () (gdb) Continuing. but in the last 2.5 hours I haven't gotten the Xlib message again. Any suggestions?
I regularly see this. Often enough that it will end up disrupting pretty much every session. Fortunately I haven't seen any data loss as a result of having to force-close the f-spot window, but it is nevertheless very disruptive. It can happen at any time, not correlated with any particular operation. It seems pretty clear to me that there's some f-spot bug in which its trying to do UI stuff from more than one thread, which isn't supposed to work (see http://www.mono-project.com/FAQ:_Gtk#My_application_crashes_with_threads). Presumably this could strike at any time, but it seems that SMP systems exacerbate the problem from being the occasional hiccup to a serious, often-repeated bug. Xlib: unexpected async reply (sequence 0x39b49)! Xlib: sequence lost (0x400ed > 0x39b49) in reply type 0xe3!
I get these hangs too on Ubuntu Gutsy on dual core machine. Crashed two or three times in a row when filtering by tags, but after that it started working. Now it happened when trying to exit from edit mode to browse mode. Here's the stack traces of all the active threads (from kill -QUIT pid): "" tid=0x0xb7cd56d0 this=0x0x21e10: at (wrapper managed-to-native) Gdk.Pixbuf.gdk_pixbuf_render_to_drawable (intptr,intptr,intptr,int,int,int,int,int,int,int,int,int) <0x00004> at (wrapper managed-to-native) Gdk.Pixbuf.gdk_pixbuf_render_to_drawable (intptr,intptr,intptr,int,int,int,int,int,int,int,int,int) <0xffffffff> at Gdk.Pixbuf.RenderToDrawable (Gdk.Drawable,Gdk.GC,int,int,int,int,int,int,Gdk.RgbDither,int,int) <0x0005e> at IconView.DrawCell (int,Gdk.Rectangle) <0x00be0> at IconView.DrawAllCells (Gdk.Rectangle) <0x001a3> at IconView.OnExposeEvent (Gdk.EventExpose) <0x00097> at Gtk.Widget.exposeevent_cb (intptr,intptr) <0x00062> at (wrapper native-to-managed) Gtk.Widget.exposeevent_cb (intptr,intptr) <0xffffffff> at (wrapper managed-to-native) Gtk.Adjustment.gtk_adjustment_set_value (intptr,double) <0x00004> at (wrapper managed-to-native) Gtk.Adjustment.gtk_adjustment_set_value (intptr,double) <0xffffffff> at Gtk.Adjustment.set_Value (double) <0x00023> at IconView.ScrollTo (int,bool) <0x000d7> "" tid=0x0xb37ffb90 this=0x0x21640: at IconView.ScrollTo (int) <0x0000f> at MainWindow.JumpTo (int) <0x00059> "" tid=0x0xb36feb90 this=0x0x21578: at (wrapper managed-to-native) System.Threading.Monitor.Monitor_wait (object,int) <0x00004> at (wrapper managed-to-native) System.Threading.Monitor.Monitor_wait (object,int) <0xffffffff> at (wrapper managed-to-native) System.Threading.Monitor.Monitor_wait (object,int) <0x00004> at System.Threading.Monitor.Wait (object) <0x0002d> at (wrapper managed-to-native) System.Threading.Monitor.Monitor_wait (object,int) <0xffffffff> at PixbufLoader.WorkerThread () <0x0008f> at System.Threading.Monitor.Wait (object) <0x0002d> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void () <0xffffffff> at FSpot.PixbufCache.WorkerTask () <0x0005d> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void () <0xffffffff> at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> "" tid=0x0xb4e36b90 this=0x0x217d0: at (wrapper managed-to-native) System.Threading.WaitHandle.WaitOne_internal (intptr,int,bool) <0x00004> at (wrapper managed-to-native) System.Threading.WaitHandle.WaitOne_internal (intptr,int,bool) <0xffffffff> at System.Threading.WaitHandle.WaitOne () <0x00055> at Banshee.Database.QueuedSqliteDatabase.ProcessQueue () <0x0015a> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void () <0xffffffff> at (wrapper runtime-invoke) System.Object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff> at MainWindow.SetViewMode (MainWindow/ModeType) <0x000f3> at MainWindow.HandlePhotoViewKeyPressEvent (object,Gtk.KeyPressEventArgs) <0x000d1> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void_object_KeyPressEventArgs (object,Gtk.KeyPressEventArgs) <0x0005d> at (wrapper delegate-invoke) System.MulticastDelegate.invoke_void_object_KeyPressEventArgs (object,Gtk.KeyPressEventArgs) <0xffffffff> at Gtk.Widget.KeyPressEventSignalCallback (intptr,intptr,intptr) <0x001c9> at (wrapper native-to-managed) Gtk.Widget.KeyPressEventSignalCallback (intptr,intptr,intptr) <0xffffffff> at (wrapper managed-to-native) Gtk.Application.gtk_main () <0x00004> at (wrapper managed-to-native) Gtk.Application.gtk_main () <0xffffffff> at Gtk.Application.Run () <0x00007> at Gnome.Program.Run () <0x00007> at FSpot.Driver.Main (string[]) <0x00858> at (wrapper runtime-invoke) System.Object.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff> Unhandled Exception: System.Threading.SynchronizationLockException: Object is not synchronized at System.Threading.Monitor.Wait (System.Object obj) [0x00000] at PixbufLoader.WorkerThread () [0x00000] at (wrapper delegate-invoke) System.MulticastDelegate:invoke_void () System.Threading.SynchronizationLockException: Object is not synchronized at System.Threading.Monitor.Wait (System.Object obj) [0x00000] at FSpot.PixbufCache.WorkerTask () [0x00000] If I read it correctly the first two threads are trying to do some GTK stuff when the gtk_main() is run by a totally different thread. Hope that helps.
As this bug made me unable to efficienly work with F-Spot, I did some investigation on it. Seems to me that ImageFile.cs, line 35 crashes F-Spot, the call to Gnome.Vfs.VfsStream. According to http://www.mono-project.com/FAQ:_Gtk#My_application_crashes_with_threads the "Xlib: unexpected async reply (sequence 0x146)!" error message is triggered by invoking a Gtk# method from a thread other than the main thread that has invoked Application.Run, but after investigating the code paths that lead to this call, it seems to me that it's invoked from the main thread. Which brings me to my question: is there a way to create threads from Mono other than new Thread() ?
I run on this problem constantly (every 10-20 minutes) on Ubuntu Gutsy on a 1st gen. Macbook: Xlib: unexpected async reply (sequence 0x15d880)! I've verified this problem on F-spot 0.4.0 (from repositories) and on F-Spot 0.3.5 (built from source). I have not yet encountered any data corruption but I have to forcibly quit F-Spot every time, which is very annoying. I have not yet found out what triggers this, because it seems quite random; sometimes leaving/entering edit mode triggers this, sometimes scrolling the image tag sidebar is enough. I'm running Compiz Fusion if that makes a difference.
Some additional info after 20+ freezes :) Sometimes the whole X (excluding the mouse cursor) freezes when this bug is triggered. This means I have to SSH in an kill my X session to recover. Killing F-spot might be enough, though. Sometimes X freezes partially so that I can switch workspaces with keyboard (in Compiz Fusion) but nothing else. Windows don't respond to mouse clicks. The bug usually gets triggered when dragging tags to images, but that might be a coincidence. Sometimes F-spot freezes spontaneously without any interaction from user.
I think X only gets freezed by F-Spot when used with Compiz Fusion. I'm not sure freezing is triggered by F-Spot, but more by Compiz Fusion. I think F-Spot should be tested without Compiz Fusion to focus on the actual bug. Could you test freezing without Compiz Fusion? You could switch back to Metacity for awhile when testing. I can confirm your observation that crashing is especially frequent when dragging tags to images. Do you use a multi-core system by any chance? What distribution you use?
*** Bug 333071 has been marked as a duplicate of this bug. ***
Please have a look at dup bug 333071, it has a lot of comments (and I didn't want to copy all of them). I'm experiencing this bug, even if (luckily) not so often, on Ubuntu Gutsy using SVN F-Spot. I never had this problem when I was running Gentoo unstable. My CPU is a Turion64, so no dual core.
It has been suggested that this bug might be triggered by Compiz Fusion. I'll test F-Spot without Compiz (with Metacity) at thursday or friday and report if the problem goes away. Feel free to do the same even sooner if you wish :).
This bug is *not* triggered by Compiz Fusion. I use Metacity and this bug agressively persists.
Maxxer (comment #7): whenever it's possible, while marking a bug as duplicate, please mark the more recent one as a dup of the older *** This bug has been marked as a duplicate of 333071 ***