Bug 488223 - New libgxim breaks xterm
New libgxim breaks xterm
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: libgxim (Show other bugs)
10
i386 Linux
low Severity high
: ---
: ---
Assigned To: Akira TAGOH
Fedora Extras Quality Assurance
:
: libgxim/swing 488307 488411 488445 488495 488601 489131 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-03 05:29 EST by Alfredo Ferrari
Modified: 2009-03-13 02:25 EDT (History)
16 users (show)

See Also:
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 11:28:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
xsession-erros related to the bug (9.78 KB, text/plain)
2009-03-03 05:31 EST, Alfredo Ferrari
no flags Details

  None (edit)
Description Alfredo Ferrari 2009-03-03 05:29:13 EST
Description of problem:
the newly released libgxim-0.3.2-3 breaks kyeboard input in xterm

Version-Release number of selected component (if applicable):
libgxim-0.3.2-3.fc10

How reproducible:
always

Steps to Reproduce:
1.login in graphical mode (gnome in my case)
2.open an xterm
3.try to type whatever in the xterm
  
Actual results:
no typing and lots of errors in .xsession-errors

Expected results:
typing should occur

Additional info:
perhaps checking the updates for basic functionality before release should not be so bad. I checked in koji no F10 version has been built/tested for months
Comment 1 Alfredo Ferrari 2009-03-03 05:31:36 EST
Created attachment 333862 [details]
xsession-erros related to the bug

.xsession-errors
Comment 2 Alfredo Ferrari 2009-03-03 06:09:37 EST
... checked on a x86_64, same result, the bug is there on x86_64 architectures as well
Comment 3 Akira TAGOH 2009-03-03 07:59:07 EST
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.
Comment 4 Akira TAGOH 2009-03-03 09:34:23 EST
*** Bug 488242 has been marked as a duplicate of this bug. ***
Comment 5 Akira TAGOH 2009-03-03 09:42:09 EST
Fixed in libgxim-0.3.2-4.fc10.
Comment 6 Fedora Update System 2009-03-03 09:43:53 EST
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
Comment 7 Akira TAGOH 2009-03-03 09:45:46 EST
Please vote if it works for you. that would speeds up to push to stable..
Comment 8 Alfredo Ferrari 2009-03-03 09:53:05 EST
i386: it works (5 minute test of course...), I am going to test a x86_64 machine....
Comment 9 Alfredo Ferrari 2009-03-03 09:56:44 EST
... and it works on x86_64 as well (few minutes...)

Great responsiveness!!  Thanks a lot
Comment 10 Dave Allan 2009-03-03 10:42:14 EST
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.
Comment 11 bobpoljakov 2009-03-03 17:41:33 EST
Works for me too. Thanks.
Comment 12 Arne Woerner 2009-03-03 17:46:10 EST
for me and my 2nd Life client, too... :-) *OOT! OOT!* -Arne
Comment 13 Henrique Martins 2009-03-03 18:27:06 EST
*** Bug 488307 has been marked as a duplicate of this bug. ***
Comment 14 Henrique Martins 2009-03-03 18:36:53 EST
Works for me too on i386, 10 minute test ...
Comment 15 Joachim Frieben 2009-03-04 00:11:26 EST
Updating to libgxim-0.3.2-4.fc10.x86_64 does fix the issue.
Comment 16 Akira TAGOH 2009-03-04 00:20:44 EST
Thanks for testing. Although the package isn't yet pushed to testing even, that may be better requesting pushing to stable now.
Comment 17 Michael Forrest 2009-03-04 03:20:27 EST
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.
Comment 18 cornel panceac 2009-03-04 07:39:21 EST
after updating to libgxim-0.3.2-4.fc10.i386, i have again keyboard in qemu and wine. thnx a lot!
Comment 19 Joachim Frieben 2009-03-04 10:35:03 EST
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.
Comment 20 Fedora Update System 2009-03-04 11:27:59 EST
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.
Comment 21 Joshua Baker-LePain 2009-03-04 12:47:49 EST
*** Bug 488495 has been marked as a duplicate of this bug. ***
Comment 22 Miroslav Lichvar 2009-03-04 16:55:07 EST
*** Bug 488601 has been marked as a duplicate of this bug. ***
Comment 23 Akira TAGOH 2009-03-04 21:46:48 EST
(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.
Comment 24 Akira TAGOH 2009-03-05 04:42:21 EST
*** Bug 488445 has been marked as a duplicate of this bug. ***
Comment 25 Akira TAGOH 2009-03-05 06:47:28 EST
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,
Comment 26 Kevin Kofler 2009-03-07 18:10:51 EST
*** Bug 488411 has been marked as a duplicate of this bug. ***
Comment 27 Kevin Kofler 2009-03-07 18:10:55 EST
*** Bug 489131 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.