| Summary: | Some programs (emacs,urxvt) hang at xcb_wait_for_event | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Daniel Clemente <n142857> |
| Component: | Lib/Xlib | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | medium | CC: | b.riefenstahl, freedesktop, peter.hutterer, psychon |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
I don't think what I found is related, but can you attach your Xorg.log please? from a session where you did reproduce that bug. And more specifically, do you have a custom xorg.conf? I'll send the Xorg.log when I can reproduce this again. I'm not using custom xorg.conf (I have no /etc/X11/xorg.conf). xserver-xorg==1:7.7+7 from Debian testing. I don't know whether this is related: lastly I have experienced hyperthrashing due to few RAM and too many simultaneous programs, for that reason some programs are hung for some seconds until thrashing finishes. I cannot guarantee that the hang happened in those moments. But I hope no xorg code depends on a function running fast. probably not the same issue then, sorry. mine requires a InputDevice section in the xorg.conf It just happened again (emacs, with the same stack trace I pasted above) and I confirm: - no message at Xorg.0.log - no relation with hyperthrashing (I now have many free Gb of RAM) or slow programs under stress; the hang happens during normal conditions The nearest „strange thing“ I did before the hang was to change window (as I do hundreds of times each day) with wmii. Just FYI; I think I'm experiencing the same bug with both of urxvt v9.14 from Ubuntu 12.04.4 APT and urxvt v9.20 from SF.net tarball. A burst of visual bells (such caused by pressing 'k' on less, perhaps with "xset r rate 200 100") reproducibly causes urxvt to hang. When I rebuilt urxvt with --disable-xim, the problem disappered. My XIM server is ibus 1.4.1-3ubuntu1. I guess this is related to https://bugzilla.redhat.com/show_bug.cgi?id=452849#c19 According to Akira's analysis, it was a deadlock of an X client, though he could find a workaround at his XIM server wrapper side. A stack trace from urxvt v9.20 #0 0x00007ffff75b7a08 in __GI___poll (fds=0x7fffffffa5b0, nfds=1, timeout=<optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:83 #1 0x00007ffff72ba862 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007ffff72bc01f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007ffff7ae2ba8 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 0x00007ffff7aca390 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #5 0x00007ffff7b12d64 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #6 0x00007ffff7b13b09 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #7 0x00007ffff7b13d8b in _XimRead () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #8 0x00007ffff7b01879 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #9 0x00007ffff7aefd3e in XSetICValues () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #10 0x000000000041af40 in rxvt_term::im_send_spot (this=0x71b4b0) at main.C:1266 #11 0x000000000040f0fa in rxvt_term::flush (this=0x71b4b0) at command.C:1021 #12 0x000000000041ff82 in rxvt_term::scr_bell (this=0x71b4b0) at screen.C:1966 #13 0x000000000040c839 in rxvt_term::cmd_parse (this=0x71b4b0) at command.C:2376 #14 0x0000000000411e14 in rxvt_term::pty_cb (this=0x71b4b0, w=..., revents=1) at command.C:1244 #15 0x00000000004298c0 in ev_invoke_pending () at ./../libev/ev.c:3061 #16 0x000000000042aad1 in ev_run (flags=<optimized out>) at ./../libev/ev.c:3461 #17 0x000000000040a3f5 in main (argc=1, argv=0x7fffffffdf38) at rxvt.C:38 I support last comment, that's a good finding. It seems fast keyboard input helped me to reproduce the bug in some cases (but still very seldom! even with xset and visual bell in screen), and it seems that disabling XIM in Emacs (through .Xresources) keeps Emacs safe. Anyway I had seen the bug also with slow keyboard input (that is, without holding keys for seconds, just typing normally). After 4 months of daily use of urxvt and a XIM-less emacs (as in previous comment), I can state again: Emacs has never hung anymore, while urxvt has, though very rarely (I think just once, right now). It seemed related to typing while urxvt was loading. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/lib/libx11/issues/35. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Hi, in last months (early 2014) I started seeing strange hangs in Emacs and urxvt which I think are due to XCB. I use GNU/Linux Debian with libxcb1==1.10-2, wmii==3.10~20120413+hg2813-6 window manager. The program window becomes black and doesn't react to mouse/keyboard events or kill signals (I tried many numbers). I have to kill the process (or mess up gdb until it dies with SIGSEGV). Same for both programs. *) Emacs hung. Version: GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 2014-04-19 (gdb) bt #0 0x00007f3e744de710 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f3e73fea232 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007f3e73febd0f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007f3e75aa3918 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 0x00007f3e75a8beb1 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #5 0x00007f3e75ad2764 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #6 0x00007f3e75ad33c0 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #7 0x00007f3e75ad36b1 in _XimRead () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #8 0x00007f3e75ac2096 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #9 0x00007f3e75ab02fd in XSetICValues () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #10 0x000000000050f099 in xic_set_preeditarea (w=0x5113858, x=768, y=56) at xfns.c:2106 #11 0x0000000000504c0a in x_draw_window_cursor (w=0x5113858, glyph_row=0x18039870, x=768, y=56, cursor_type=FILLED_BOX_CURSOR, cursor_width=1, on_p=true, active_p=true) at xterm.c:7312 #12 0x0000000000477484 in display_and_set_cursor (w=0x5113858, on=true, hpos=96, vpos=4, x=768, y=56) at xdisp.c:27214 #13 0x00000000004f7070 in x_update_window_end (w=0x5113858, cursor_on_p=true, mouse_face_overwritten_p=false) at xterm.c:582 #14 0x00000000004133ae in update_window (w=0x5113858, force_p=true) at dispnew.c:3486 #15 0x00000000004129f8 in update_window_tree (w=0x5113858, force_p=true) at dispnew.c:3161 #16 0x00000000004129bd in update_window_tree (w=0x524ef10, force_p=true) at dispnew.c:3159 #17 0x00000000004126d1 in update_frame (f=0x5113640, force_p=true, inhibit_hairy_id_p=false) at dispnew.c:3059 #18 0x000000000044b5ee in redisplay_internal () at xdisp.c:13873 #19 0x00000000004495cd in redisplay () at xdisp.c:13056 #20 0x00000000005292ed in read_char (commandflag=1, map=375333574, prev_event=12839794, used_mouse_menu=0x7fff8cc0c69f, end_time=0x0) at keyboard.c:2751 #21 0x0000000000534c1a in read_key_sequence (keybuf=0x7fff8cc0c880, bufsize=30, prompt=12839794, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9076 #22 0x0000000000526840 in command_loop_1 () at keyboard.c:1449 #23 0x00000000005b3a60 in internal_condition_case (bfun=0x526487 <command_loop_1>, handlers=12890850, hfun=0x525d99 <cmd_error>) at eval.c:1354 #24 0x00000000005261e1 in command_loop_2 (ignore=12839794) at keyboard.c:1174 #25 0x00000000005b3272 in internal_catch (tag=12886738, func=0x5261bb <command_loop_2>, arg=12839794) at eval.c:1118 #26 0x000000000052618f in command_loop () at keyboard.c:1153 #27 0x0000000000525994 in recursive_edit_1 () at keyboard.c:777 #28 0x0000000000525b01 in Frecursive_edit () at keyboard.c:845 #29 0x0000000000523acf in main (argc=2, argv=0x7fff8cc0cd08) at emacs.c:1654 * urxvt hung. rxvt-unicode==9.19-1. Started with daemon: urxvtcd (gdb) bt #0 0x00007f1b40226710 in __poll_nocancel () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007f1b3f481232 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #2 0x00007f1b3f482d0f in xcb_wait_for_event () from /usr/lib/x86_64-linux-gnu/libxcb.so.1 #3 0x00007f1b4166d918 in _XReadEvents () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #4 0x00007f1b41655eb1 in XIfEvent () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #5 0x00007f1b4169c764 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #6 0x00007f1b4169d3c0 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #7 0x00007f1b4169d6b1 in _XimRead () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #8 0x00007f1b4168c096 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #9 0x00007f1b4167a2fd in XSetICValues () from /usr/lib/x86_64-linux-gnu/libX11.so.6 #10 0x00000000004281bf in rxvt_term::im_send_spot() () #11 0x000000000041e6d9 in rxvt_term::flush() () #12 0x0000000000438640 in ev_invoke_pending() () #13 0x000000000043989e in ev_run () #14 0x0000000000418e87 in main () (gdb) In addition I'm using scim (input method). If there's some way in which I can advance the research of this bug, please tell me. It happens rarely, maybe once a week. I didn't see any pattern. I tried as a workaround to go up the stack and then forcing „return“ in gdb but it only crashed or hung again. Tips to unblock apps are welcome.