Bug 134930
| Summary: | turning Xinerama on freezes XIM | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Akira TAGOH <tagoh> | ||||||||
| Component: | xorg-x11 | Assignee: | Søren Sandmann Pedersen <sandmann> | ||||||||
| Status: | CLOSED UPSTREAM | QA Contact: | David Lawrence <dkl> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | rawhide | CC: | eng-i18n-bugs, grant_gayed, kem, morpheus, redhat-bugzilla, xgl-maint | ||||||||
| Target Milestone: | --- | Keywords: | i18n | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2006-06-27 17:40:28 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Bug Depends On: | |||||||||||
| Bug Blocks: | 150223, 182226 | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 104884 [details]
my xorg.conf
Created attachment 104886 [details]
result of lspci
attach the X server log file also please. By 'freeze' do you mean the server stops responding, or can you still interact with other applications? Also, does this happen on both monitors, or only on one of them? And as Mike said, please attach the server log file (in /var/log/Xorg.*.log). server stops responding Created attachment 105185 [details] a log file Comment #4: well, for me, only that application stops responding, but others was fine. and this happened on both monitors. also, not sure if it's helpful, that application sometimes worked again after waiting awhile. but it maybe continues stoped When you get a stuck application, could you try running gdb --pid <pid of application> then type bt and post the resulting backtrace here? Thanks Ideally the backtrace should be from a gtk2 application as that is the toolkit I am most familar with. well, I don't have the way to reproduce this problem on gtk2 for sure.
though I'll try on gtk2, here is the backtrace from KDE application:
(gdb) bt
#0 0x0031eec8 in ___newselect_nocancel () from /lib/tls/i686/libc.so.6
#1 0x003f3f92 in _XEnq () from /usr/X11R6/lib/libX11.so.6
#2 0x003f436e in _XRead () from /usr/X11R6/lib/libX11.so.6
#3 0x003f6165 in _XReadEvents () from /usr/X11R6/lib/libX11.so.6
#4 0x003de810 in XIfEvent () from /usr/X11R6/lib/libX11.so.6
#5 0x001c83dd in _XimThaiCloseIM ()
from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#6 0x001c8a54 in _XimWrite ()
from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#7 0x001c8cf2 in _XimRead ()
from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#8 0x001b5d0e in _XimUnregisterServerFilter ()
from /usr/X11R6/lib/X11/locale/lib/common/ximcp.so.2
#9 0x0040e2ff in XSetICValues () from /usr/X11R6/lib/libX11.so.6
#10 0x0017ac50 in QXIMInputContext::setComposePosition
(this=0x8bfbfb0, x=5,
y=77) at qximinputcontext_x11.cpp:799
#11 0x0017ab52 in QXIMInputContext::setMicroFocus (this=0x8bfbfb0, x=1724,
y=117, h=15, f=0xfee07e60) at qximinputcontext_x11.cpp:764
#12 0x00169c5d in QMultiInputContext::setMicroFocus (this=0x8e8c788,
x=1724,
y=117, w=0, h=15, f=0xfee07e60) at qmultiinputcontext.cpp:150
#13 0x0611a790 in QWidget::setMicroFocusHint (this=0x8da5a18, x=5, y=3,
width=0, height=15, f=0xfffffdfe) at qpoint.h:118
#14 0x0630233a in QTextEdit::updateMicroFocusHint (this=0x8da5a18)
at qframe.h:163
#15 0x0630e885 in QTextEdit::drawContents (this=0x8da5a18, p=0xfee07fb0,
cx=52, cy=3, cw=16, ch=18) at widgets/qtextedit.cpp:1093
#16 0x062b7c13 in QScrollView::drawContentsOffset (this=0x8da5a18,
p=0xfee07fb0, offsetx=0, offsety=-514, clipx=-514, clipy=-514,
clipw=-514,
cliph=-514) at widgets/qscrollview.cpp:2334
#17 0x062b6b59 in QScrollView::viewportPaintEvent (this=0x8da5a18, pe=0x0)
at widgets/qscrollview.cpp:217
#18 0x067acb5f in KEdit::viewportPaintEvent () from /usr/lib/libkdeui.so.4
#19 0x062b9113 in QScrollView::eventFilter (this=0x8da5a18, obj=0x8da6168,
e=0xfee08600) at widgets/qscrollview.cpp:1490
#20 0x06309dd5 in QTextEdit::eventFilter (this=0x8da5a18, o=0x8da6168,
e=0xfee08600) at widgets/qtextedit.cpp:3014
#21 0x061a6982 in QObject::activate_filters (this=0x8da6168, e=0xfee08600)
at kernel/qobject.cpp:902
#22 0x061a6a3b in QObject::event (this=0x8da6168, e=0xfee08600)
at kernel/qobject.cpp:735
#23 0x061ded9a in QWidget::event (this=0x8da6168, e=0xfee08600)
at kernel/qwidget.cpp:4672
#24 0x0614a849 in QApplication::internalNotify (this=0xfffffdfe,
receiver=0x8da6168, e=0xfee08600) at kernel/qapplication.cpp:2635
#25 0x0614a9da in QApplication::notify (this=0xfee08bc0,
receiver=0x8da6168,
e=0xfee08600) at kernel/qapplication.cpp:2523
#26 0x00ac44e8 in KApplication::notify () from /usr/lib/libkdecore.so.4
#27 0x060e1baa in QETWidget::translatePaintEvent (this=0x8da6168,
event=0xfee08600) at qapplication.h:518
#28 0x060e8775 in QApplication::x11ProcessEvent (this=0xfee08bc0,
event=0xfee08a60) at kernel/qapplication_x11.cpp:3487
#29 0x060fa686 in QEventLoop::processEvents (this=0x8bb2fa8, flags=4)
at kernel/qeventloop_x11.cpp:192
#30 0x0615fe85 in QEventLoop::enterLoop (this=0x8bb2fa8)
at kernel/qeventloop.cpp:198
#31 0x0615fdde in QEventLoop::exec (this=0x8bb2fa8)
at kernel/qeventloop.cpp:145
#32 0x06149a4b in QApplication::exec (this=0xfee08bc0)
at kernel/qapplication.cpp:2758
#33 0x006d862c in kdemain () from /usr/lib/libkdeinit_kedit.so
#34 0x080485f2 in ?? ()
#35 0x00000001 in ?? ()
#36 0xfee08d94 in ?? ()
#37 0xfee08d18 in ?? ()
#38 0x0804860e in ?? ()
#39 0x00299fa1 in __cxa_atexit_internal () from /lib/tls/i686/libc.so.6
#40 0x00286ab4 in __libc_start_main () from /lib/tls/i686/libc.so.6
#41 0x0804854d in ?? ()
(gdb)
When you start httx manually in a terminal, do you get messages like "htt_server died and recovered"? Nope. even if I run httx manually, it didn't output anything, but drawing stoped working. Since I enabled xinerama, I am experiencing this too, and it leads to a complete system freeze if you try to change consoles. How to Reproduce ----------------- 1. Open quanta 2. Press CTRL-SPACE 3. Type Japanese (like bennkyou= ã¹ãããã) 4. Press SPACE to convert 5. You only can see the first kanji displayed, second is blank space (i.e. å) 6. quanta app is now frozen and will not respond to any keyboard input. You cannot turn off iiimf by pressing CTRL-SPACE again. Also, HOME, Backspace, ESC, CTRL-C, etc. do nothing. 7. Next go to any other open KDE app (like konsole). Even if you are not using IIIMF and just try to type English, you can only type one character then the app freezes. 8. From now on all KDE apps are frozen and you must reboot. 9. If you press CTRL-ALT-F1 to try to log on to a text console, the system will freeze. This bug can be reproduced using the above steps 100% of the time. In /var/log/messages, I get the following errors: Dec 21 00:20:19 enormousroom htt_server[2719]: status has not been enabled yet. (1, 6) Dec 21 00:21:08 enormousroom htt_server[2719]: status has not been enabled yet. (1, 1) Dec 21 00:21:08 enormousroom htt_server[2719]: status has not been enabled yet. (1, 6) Dec 21 00:21:09 enormousroom htt_server[2719]: status has not been enabled yet. (1, 1) Dec 21 00:21:11 enormousroom htt_server[2719]: status has not been enabled yet. (1, 1) Dec 21 00:21:12 enormousroom htt_server[2719]: status has not been enabled yet. (1, 6) Dec 21 00:21:12 enormousroom htt_server[2719]: Client shut down the connection owned by im_id(1). Dec 21 00:21:17 enormousroom htt_server[2719]: Client shut down the connection owned by im_id(1). Dec 21 00:21:17 enormousroom htt_server[2719]: status has not been enabled yet. (1, 6) Dec 21 00:21:20 enormousroom htt_server[2719]: Client shut down the connection owned by im_id(1). The "status has not been enabled yet" happens thousands of times, and I know there is a bug report open on this one. But what is "Client shut down the connection..."? My /var/log/iiim and /var/log/canna directories are empty. The problem here is that Xinerama is implemented by drawing the glyphs several times, once on each screen. For 16 bit fonts loaded from the font server, the client is put to sleep each time waiting for the font to be loaded, but only awoken once when the glyphs arrive. So what should we do fix on? We believe the fix here is going to be really involved. We don't think it will happen for FC4, so moving to FC5. This bug is now upstream: https://bugs.freedesktop.org/show_bug.cgi?id=3040 Soeren, could a similar freeze that happens whenever Xinerama is on but with locale=en_US.UTF-8 have the same cause? In particular, I see this when launching the linux-motif build of eclipse. If it only happens with core fonts and Xinerama, then yes, I would say it is likely the same bug. So far I have only seen it with 16 bit fonts, but I don't think there is any fundamental reason it couldn't happen with 8 bit fonts as well. (Or maybe a 16 bit font gets loaded even in the en_US.UTF-8 locale for some reason). A way to find out is to run it through xscope with XSynchronize() turned on. If it hangs just after issuing a text rendering request, then it is probably this bug. Setting status to "UPSTREAM" *** Bug 205982 has been marked as a duplicate of this bug. *** |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510 Description of problem: when Xinerama is turned on, XIM freezes or becomes too slow working. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.make sure that httx is running with ja_JP.UTF-8 locale 2.XMODIFIERS=@im=htt LANG=ja_JP.UTF-8 kedit 3.press ctrl+space n i h o n g o space Actual Results: rendering is freezed Expected Results: not freezed Additional info: it also happens on xemacs, gtk2 apps. but not happens with xemacs -nw. though the reproducibility is not every time, for xemacs, there is the way to reproduce this: 1. run xemacs 2. press ctrl+_ 3. choose japanese-canna for the input method 4. M-x canna-extend-mode 5. come and go into the each menu item. you will see the freeze issue then. also, after Xinerama was turned off, this problem disappears.