GNOME Bugzilla – Bug 580230
Fatal IO error 11 (Ресурс временно недоступен) on X server
Last modified: 2010-01-28 23:22:20 UTC
Steps to reproduce: time-to-time Stack trace: balsa: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.0. ** (balsa:20842): WARNING **: FIXME: wait for completion unimplemented Program exited with code 01. Other information: The phrase in Russian means Resource Temp. Unavailable.
Might be due to a very-very recent Xorg.
I also see this on one rawhide/pre-f11 laptop, but not on a desktop running the same software. The laptop is a ThinkPad T43 with Radeon video, and I can avoid the problem either by running balsa --sync or by switching from the radeon driver to vesa. I often get balsa: xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed. immediately before the X error: balsa: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0. I haven't seen the FIXME warning, though! All in all, it looks like a race condition in asynch X messaging, but I've no way to debug it. I haven't seen the same error in other apps, and I don't understand why it seems to afflict only Balsa.
Yeah, Peter. I have the Radeon driver too and I don't think it's a coincidence. (In reply to comment #2) > I haven't seen the same error in other apps, and I don't > understand why it seems to afflict only Balsa. Google says some apps had this problem (e.g. rhythmbox).
Created attachment 135912 [details] [review] patch under test The issue seems to be related to updating the display in a sub-thread. We routinely use gdk_display_flush() after any such update, and testing various changes suggests that it's the flush that triggers the error, not the actual display update. This patch fixes the situation for me--please test it!
On 08.06.2009 04:39:55, Peter Bloomfield wrote: > Master has been patched in an attempt to fix this. It's basically the patch attached to the bug, with some signal-handler fixes added. We'd be very interested to find out if it resolves your issue. I do test your patch since Build Date: Thu Jun 4 09:57:26 2009. Balsa didn't fall since then, so I treat your patch as "working".
Tested *fine* for almost a week. Today I rebuilt it with "--enable debug" and got again: > balsa: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.0. > Program exited with code 01. The "--enable debug" (generally) makes the difference: "-g" and no "-O" flags. Is it possible that unoptimized code emerge such a problem? Peter, could you please check? And I received balsa-initiated Xorg hang. After ^C in the gdb, I got: > Xlib: sequence lost (0x19038 > 0x9117) in reply type 0x6! > balsa: xcb_io.c:176: process_responses: Проверочное утверждение `!(req && current_request && !(((long) (req->sequence) - (long) (current_request)) <= 0))' не выполнено. > > Program received signal SIGABRT, Aborted. > [Switching to Thread -1233610448 (LWP 26891)] > 0xb717d2e7 in raise () from /lib/libc.so.6 BTW: On 08.06.2009 04:39:55, Peter Bloomfield wrote: > Master has been patched in an attempt to fix this. It's basically the patch attached to the bug, with some signal-handler fixes added. We'd be very interested to find out if it resolves your issue. Can't find it in "master". Could you please give me the hash of the commit? Thanks.
I inserted -O0 before -Wsign-compare in the "for option in..." loop in configure.in, and that results in "-g -O2 -O0" in the compile line, which I think does the same as your line. But...it hasn't triggered the X error (yet). I'll keep running it. The gdb output for the hang suggests to me that it's the same underlying issue--X requests somehow getting out of order. About git: sorry, I forgot to mention the bug in the log. The commit is: commit 3a609b9cec5419eb445eb668cea746eb5fd3121d Author: Peter Bloomfield <PeterBloomfield@bellsouth.net> Date: Sun Jun 7 11:54:20 2009 -0400 Update display in an idle callback ChangeLog libbalsa/mailbox.c libbalsa/mailbox.h
Created attachment 136383 [details] [review] another possible patch The previous patch (apparently only a partial fix) moved some display updates from a subthread to an idle callback in the main thread. We still update the display in a subthread in a couple of places, one of which can also easily be moved to an idle callback, but one is more problematic. This patch does the easy move--let us know if it helps.
(In reply to comment #7) > commit 3a609b9cec5419eb445eb668cea746eb5fd3121d Tested extensively for 6 days. This version works fine. Keeping in mind that balsa sometime hangs (send data in private email 29.06.2009 11:53:57 GMT+6). (In reply to comment #8) > Created an attachment (id=136383) [edit] > another possible patch Sorry, I didn't test this one yet.
(In reply to comment #8) > Created an attachment (id=136383) [edit] > another possible patch ... > This patch does the easy move--let us know if it helps. No. I got it again with this patch while sending a message. >>>> balsa: Fatal IO error 11 (Ресурс временно недоступен) on X server :0.0. Still hope that the bug would be fixed soon.
Sorry, but here's a non-Radeon instance 0:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) Balsa 2.4.0 and xorg-x11-server-Xorg-1.6.1.901-1.fc11.i586
For the protocol: if build Balsa --without-threads, the bug does not emerge. This may be referenced as workaround.
It stopped happen. I think people should check that and close this bug. Though I myself now suffer from this: https://bugzilla.gnome.org/show_bug.cgi?id=608337
Yes, you're right! I disabled the patch in comment 4, which previously would have led to a crash in short order, and nothing bad happened. I'm not going to revert the patch, however; I couldn't detect any visual effects of postponing the display update from the thread to an idle handler, and who knows when updating the display in a thread will break again. Resolving as obsolete...for now.