Bug 488223
Summary: | New libgxim breaks xterm | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Alfredo Ferrari <alfredo.maria.ferrari> | ||||
Component: | libgxim | Assignee: | Akira TAGOH <tagoh> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 10 | CC: | bjorge, bobpoljakov, cpanceac, dallan, domingobecker, fedora, hestyp, hugh, i18n-bugs, jfrieben, joshua.bakerlepain, klmitch, mark, mef, tagoh, windsor | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 0.3.2-4.fc10 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | |||||||
: | 489611 (view as bug list) | Environment: | |||||
Last Closed: | 2009-03-04 16:28:04 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: | |||||||
Attachments: |
|
Description
Alfredo Ferrari
2009-03-03 10:29:13 UTC
Created attachment 333862 [details]
xsession-erros related to the bug
.xsession-errors
... checked on a x86_64, same result, the bug is there on x86_64 architectures as well Thank you for catching this up. just tested on GNOME/GTK+ applications only. this issue seems to be introduced by a patch that fixes a memory leak and no GdkWindow instance happens after unreferencing the object during copying the object. Anyway I'll have a fix of this issue shortly. *** Bug 488242 has been marked as a duplicate of this bug. *** Fixed in libgxim-0.3.2-4.fc10. libgxim-0.3.2-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/libgxim-0.3.2-4.fc10 Please vote if it works for you. that would speeds up to push to stable.. i386: it works (5 minute test of course...), I am going to test a x86_64 machine.... ... and it works on x86_64 as well (few minutes...) Great responsiveness!! Thanks a lot I was seeing maximized xterms fail to accept keyboard input, or accepting every other character of input. I just installed libgxim-0.3.2-4, and the problem has gone away (not a lot of time elapsed, but a good datapoint). Thanks for the quick fix. Works for me too. Thanks. for me and my 2nd Life client, too... :-) *OOT! OOT!* -Arne *** Bug 488307 has been marked as a duplicate of this bug. *** Works for me too on i386, 10 minute test ... Updating to libgxim-0.3.2-4.fc10.x86_64 does fix the issue. Thanks for testing. Although the package isn't yet pushed to testing even, that may be better requesting pushing to stable now. Updating to libgxim-0.3.2-4.fc10.i386 does allxterm to work again for me, too. Sooner this gets to stable, better for everton, methinks! I also have to commend Akira for his responsiveness on this issue. after updating to libgxim-0.3.2-4.fc10.i386, i have again keyboard in qemu and wine. thnx a lot! As an update to comment #15, I have to report a serious regression of libgxim-0.3.2-4.fc10.x86_64 with respect to libgxim-0.3.1-1.fc10.x86_64: When running an application with a high rate of text output in XTERM, then "imsettings-applet" will grab about 10% of the CPU load, altough SCIM is not even enabled. Even worse: when I open "Input Method" while there is an active run in some xterm, then the respective window turns black, and the job is blocked forcing me to execute "killall xterm". Clicking the kill button would not allow to close the window. Both regressions can be overcome by reverting to libgxim-0.3.1-1.fc10.x86_64 for which the load of "imsettings-applet" drops back to virtually 0 and "Input Method" can be launched at will without affecting an active XTERM. libgxim-0.3.2-4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. *** Bug 488495 has been marked as a duplicate of this bug. *** *** Bug 488601 has been marked as a duplicate of this bug. *** (In reply to comment #19) > As an update to comment #15, I have to report a serious regression of > libgxim-0.3.2-4.fc10.x86_64 with respect to libgxim-0.3.1-1.fc10.x86_64: > When running an application with a high rate of text output in XTERM, then > "imsettings-applet" will grab about 10% of the CPU load, altough SCIM is not > even enabled. Even worse: when I open "Input Method" while there is an active > run in some xterm, then the respective window turns black, and the job is > blocked forcing me to execute "killall xterm". Clicking the kill button would > not allow to close the window. > Both regressions can be overcome by reverting to libgxim-0.3.1-1.fc10.x86_64 > for which the load of "imsettings-applet" drops back to virtually 0 and "Input > Method" can be launched at will without affecting an active XTERM. Can you file a bug separately please? That might be a side-effect to take care of memory leaks perhaps though. but let me try to analyse and see if there are any possibilities to improve a performance. *** Bug 488445 has been marked as a duplicate of this bug. *** I should have more comment about black-out issue. this basically happens if there are no replies expected from XIM server, correctly something you have in XMODIFIERS envvar. There may be a potential issue in xterm as well since it doesn't support reconnecting XIM session when disconnected accidentally though, it's a different issue that looks like IM doesn't work after switching etc. libgxim aims to not block any events and trying to keep its working as minimum even if IM itself doesn't work. so if you have a certain step to reproduce that, that would be really helpful to get rid of that issue. Anyway, when in doubt, please feel free to file a bug against libgxim. I'll have a look and try to fix that as far as possible. Thanks, *** Bug 488411 has been marked as a duplicate of this bug. *** *** Bug 489131 has been marked as a duplicate of this bug. *** |