Bug 569257

I tried to reproduce this bug on both rhel5.4 and 5.3 i386 machines, but I cannot reproduce it (i.e. I have everything set up as you mentioned above but the problem does not occur for me). 

Is the problem still occurring for you (even though it has only been a month since it was reported, but maybe there was an update that fixed it)?

Thanks,
Man Lung Wong

Oh, I forgot enabling scim at reploducer.
Please add follwoing step:

1.1. install im-chooser 
1.2. execute "im-chooser". Select SCIM and re-login.

Thanks,
Kazuo Moriwaka

Those step did not seem to have help. And from your reply it seems the problem still exists (am I correct).

Thanks,
Man Lung Wong

Okay, I seem to be able to reproduce this problem. I was trying to reproduce it through VNC before, which I guess is the reason why the problem does not occur.

Man Lung Wong

Thank you for your effort.  I see same problem at latest packages.

If you are not using the deadkeys, then you can use the following workaround for now:

1.) Open ~/.scim/config with your favorite editor.
2.) Edit the line that reads "/FrontEnd/X11/Dynamic = blah", the blah should be 
    change to true, if it was false (which it should be if you never touched it).
3.) Logout and Login. Scim will still be enabled and working (except for the 
    deadkeys) and the keyboard lock up should not happen.

I tested it out on my RHEL5.4 system and the workaround works fine.

In case you are wondering where the workaround came from... here is the link https://bugs.launchpad.net/ubuntu/+source/scim/+bug/66104

The above bug, from what I understand is related to this bug, meaning this would be related to xorg and not openjdk. However, I still need to look into it more before I reassign it.

Thanks for your patient,
Man Lung Wong

This workaround works well. 

Thank you!

For your info, I've noticed that RHDS8.1 with java-1.4.2-gcj-compat-1.4.2.0-40jpp.115 works without this workaround. I don't check other all functions.  RHDS isn't supported with gcj.

Best Regards,

What do you mean by RHSD8.1 with java-1.4.2-gcj-compat-1.4.2.0-40jpp.115, because I have both installed. Sorry if it is something obvious.

Thanks for the info,
Man Lung Wong

RHEL can choose 'java' command's backends by alternative.  /etc/alternative/java links to openjdk's 'java' or gcj's 'java'.
What I wanted to say by "RHDS 8.1 with java-1.4.2-gcj" is gcj's java is linked from /etc/alternative/java. 

redhat-idm-console script choose JVM by 'which java' is setuped by /etc/alternative/java link.


redhat-idm-console works with following set:
Set A:
- java-1.4.2-gcj-compat's JVM 
- SCIM enabled 
- "/FrontEnd/X11/Dynamic = false" config 

Set B:
- java-1.6.0-openjdk's JVM 
- SCIM enabled 
- "/FrontEnd/X11/Dynamic = true" config 

redhat-idm-console doesn't work with following set:
Set C:
- java-1.6.0-openjdk's JVM 
- SCIM enabled 
- "/FrontEnd/X11/Dynamic = false" config 

I feel that this situation imply something in OpenJDK has problem with X treatment.

Thank you,

Can you post what you get with "ls -la /etc/alternative/java" and "ls -la "/etc/alternative/javac"?

Thanks,
Man Lung Wong

When you link to gcj instead of openjdk?

Thanks,
Man Lung Wong

When I link /etc/alternatives/java to /usr/lib/jvm/jre-1.6.0-openjdk/bin/java, this problem appear. 
When I link /etc/alternatives/java to /usr/lib/jvm/jre-1.4.2-gcj/bin/java, this problem doesn't appear.

Thanks,

I was actually more curious at what javac is linked to because my /usr/lib/jvm/jre-1.4.2-gcj folder do not have javac.

Man Lung Wong

Whoops... I meant the java-1.4.2-gcj folder.

Man Lung Wong

I'm sorry I didn't make clear about javac. 

When I tried with java-1.4.2-gcj package, I didn't installed openjdk package, so any javac isn't installed.   And RHDS's admin console doesn't call javac. 

Thank you,

That should not be possible because redhat-ds depends on openjdk. And I have tried redhat-idm-console with gcj installed and java set up as you mentioned above, without javac, however it still gives me:

Exception in thread "main" java.lang.ClassFormatError: com.netscape.management.client.console.Console (unrecognized class file version)
   at java.lang.VMClassLoader.defineClass(libgcj.so.7rh)
   at java.lang.ClassLoader.defineClass(libgcj.so.7rh)
   at java.security.SecureClassLoader.defineClass(libgcj.so.7rh)
   at java.net.URLClassLoader.findClass(libgcj.so.7rh)
   at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.7rh)
   at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
   at java.lang.ClassLoader.loadClass(libgcj.so.7rh)
   at gnu.java.lang.MainThread.run(libgcj.so.7rh)

So can you give me the exact steps as to how you got it to work with gcj.

FYI: I tested with oracle's java and that has the same problem (i.e. password field lock up with scim enabled).

Thanks,
Man Lung Wong

I found my test environment has RHDS 8.0.  
I'm sorry very much for I've confused you.
And I checked RHDS8.1's idm-console-framework package has dependency for java 1.6.0.

So does that mean you can't run RHDS 8.1 with gcj?

Thanks,
Man Lung Wong

This problem isn't specific to openjdk -- I get it with both jrockit and sun jdk as well.  I have a tiny java program that I can use to demonstrate the problem.

(In reply to comment #20)
> This problem isn't specific to openjdk -- I get it with both jrockit and sun
> jdk as well.  I have a tiny java program that I can use to demonstrate the
> problem.

Could please attach the reproducer? Thanks.

Created attachment 454572 [details]
Test Program

javac PasswdTest.java
tar cfe test.tar PasswdTest PasswdTest*.class
java -jar test.jar

You don't need to wrap the test program up in a jar, I did it because it's just one file to copy around between machines.

With scim running (and without "/FrontEnd/X11/Dynamic = true" in ~/.scim/config) you'll find that you can merrily type in the text field, but nothing happens when you try to type in the passwd field.

If you click on "Show Values" then you'll see there was nothing in the passwd field (as expected) but now, interesting, when you dismiss that dialog you can type in the passwd field.

Running "kill $(pgrep scim)" gets rid of the scim processes (obviously) and the program works again.

The problem confused me for ages: you do need scim running and if you're in any environment where it's not present (eg ssh -X -Y localhost) then the program works.

Interestingly, I can only reproduce the problem in a Xen guest and it shows up on both the console and a VNC server running in the guest.  The same VNC server running in a bare-metal installation doesn't show the same problem, at least not for me.   I'm beginning to think that this is something that scim is doing based on what it thinks is its environment.

(In reply to comment #23)
> Interestingly, I can only reproduce the problem in a Xen guest and it shows up
> on both the console and a VNC server running in the guest.  The same VNC server
> running in a bare-metal installation doesn't show the same problem, at least
> not for me.   I'm beginning to think that this is something that scim is doing
> based on what it thinks is its environment.

I think so too. Using fedora, I can reproduce the problem using scim, but not using ibus.