United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6901233 Java GUI core dumping when using Chinese UTF-8 locale in 64 bit mode on Solaris 10 Update 2 and abov
JDK-6901233 : Java GUI core dumping when using Chinese UTF-8 locale in 64 bit mode on Solaris 10 Update 2 and abov

Details
Type:
Bug
Submit Date:
2009-11-13
Status:
Closed
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2010-01-06
Component:
vm-legacy
OS:
solaris
Sub-Component:
runtime
CPU:
generic
Priority:
P2
Resolution:
Duplicate
Affected Versions:
solaris_10
Fixed Versions:
6-pool

Related Reports

Sub Tasks

Description
Submitting this bug on behalf of Symantec. They our are partner and we resell their NetBackup product. They are having an issue with the java GUI on Solaris 10 update 2 and above. I have attached the core file they submitted to this bug. If this is not the correct category for the bug, please let me know which one is and I will move it there. Thanks for your help.

Here are the details:

----------------------------------------------------------------------------------

"When the NBU java GUI is launched, clicking of any button on the Login dialog crashes the GUI. JRE used to launch the application is 1.6.0_16 with -d64 flag i.e. the 64 bit JVM server is used.

Also this happens only on simplified Chinese-UTF-8 locale. With any other locale on the same machine it is running fine. Also the crash is not seen, if 32 bit JVM is used to launch the application.

We also did a simple program in java swing which uses a Frame and a button and ran it with the 64 bit JRE. The same crash is reproduced for this program as well.

Also this is not a JRE issue as it can be seen with 1.4.2/1.5 64 bit as well.

 

Machine details:

bash-3.00# uname -a

SunOS akshaysol 5.10 Generic_141444-09 sun4u sparc SUNW,Sun-Blade-100

 

Sun OS 5.10 is on update 8.

 

Locale:

bash-3.00# locale

LANG=zh_CN.UTF-8

LC_CTYPE="zh_CN.UTF-8"

LC_NUMERIC="zh_CN.UTF-8"

LC_TIME="zh_CN.UTF-8"

LC_COLLATE="zh_CN.UTF-8"

LC_MONETARY="zh_CN.UTF-8"

LC_MESSAGES=zh_CN.UTF-8

LC_ALL=

"
----------------------------------------------------------------------------------
Symantec has provided a reproduceable test case. Attached to this bug is a file called example.jar. Extract the jar file into a directory (work in this example) and then, from inside the directory, execute command:

java -d64 SwingExample

which will launch a sample GUI. Click the "Test" button and a core file is generated. 

Note that to get this to work correctly I had to remote login to my test machine so I could access the full graphical desktop of the machine with the Simplified Chinese UTF-8 installed. If I login via a terminal from my desktop, the desktop takes on attributes from the locale on my machine and I cannot reproduce the bug in that instance. 

I also verified the core is not generated if the -d64 flag is not used.
Below are the login instructions for my test machine that has this issue setup to reproduce. Please work on this as soon as possible, as this issue is very hot for Symantec, and could hold up the release of their software which Sun also releases and sells. Thanks.

machine name: u80-14.central.sun.com
login: root
password: root

Note: I had to do a remote login from the GUI login screen on my local machine, so I had the full Gnome instance on u80-14 loaded. If I just launch a terminal from my regular session, it takes on the properties of the local locale, instead of the Simplified Chinese locale, and I cannot reproduce the bug.

Once you complete the remote GUI login here are the steps:

1. Open terminal window
2. Change directory to the location of the program:

cd /export/work

3. Contents of directory are as follows:
example.jar           SwingExample$1.class
META-INF              SwingExample.class

4. Run command:

java -d64 SwingExample

5. Click on the "Press Me" button and the core & hserror logs are generated in the /export/work directory.

6. If you repeat procedure without the -d64 flag, no core is generated so this only affects 64 bit java.

                                    

Comments
PUBLIC COMMENTS

Any status on this bug? Thanks.
                                     
2009-12-01
EVALUATION

java crashes in native method xaux_object_get_classname_from_utfname() in auxiliary_object.so, which is part of native
X11 implementation of Client Framework for Internet/Intranet Input Method (IIIM). Hence, it doesn't depend on JDK version.

Native part of call stack is as follows:

auxiliary_object.so    xaux_object_get_classname_from_utfname+0x58()
auxiliary_object.so    xaux_so_Draw+0x64()
xiiimp.so.2        IIimpAuxDraw+0x4c()
xiiimp.so.2        IMProcessIncomingEvent+0x2a0()
xiiimp.so.2        IMChangeFocus+0x64()
xiiimp.so.2        _Ximp_Local_SetFocus+0x5c()
libX11.so.4        XSetICFocus+0x78()
libmawt.so        setXICFocus+0x58()
libmawt.so        Java_sun_awt_X11_XInputMethod_setXICFocusNative+0x110()

It's reproducible with all java applications from $JAVA_HOME/demo/jfc. It doesn't depend on Chinese usage in the application since it's used in auxiliary windows, where the crash occurs.

Looks like the bug should crash all native X11 applications as well, that use 64-bit auxiliary_object.so. For instance, it can be reproducible with /usr/bin/sparcv9/gtk-demo, that crashes exactly on the same instruction in xaux_object_get_classname_from_utfname().
                                     
2009-12-07
EVALUATION

fixed in 6907926

Solaris patches:

120410-33/120411-33: iiimf core patch
120412-11/120413-11: Simplified Chinese patch
120414-25/120415-25: Asian patch other than S-Chinese
                                     
2009-12-21
EVALUATION

This CR is a duplicate of 6907926.
                                     
2010-01-06



Hardware and Software, Engineered to Work Together