• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • DSO:L1
  • hhuynh
  • Reporter: mruddy
  • February 02, 2009
  • 0
  • Watchers: 1
  • April 20, 2009
  • March 05, 2009

Attachments

Description

/usr/java/bin/java -version
java version “1.5.0_16” Java(TM) Platform, Standard Edition for Business (build 1.5.0_16-b02) Java HotSpot(TM) Server VM (build 1.5.0_16-b02, mixed mode)

/usr/java/bin/java -version -d64 java version “1.5.0_16” Java(TM) Platform, Standard Edition for Business (build 1.5.0_16-b02) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_16-b02, mixed mode)

cat /etc/release Solaris 10 10/08 s10x_u6wos_07b X86

JBoss [EAP] 4.3.0.GA_CP03

with libsigar installed as mentioned in CDV-1109…

starting as a 32-bit process starts up and runs a small test application successfully.

adding “-d64” to the jboss app server’s java command line to run as a 64-bit process fails with the following stack trace:

./jboss-eap-4.3/jboss-as/bin/tc-run.sh Starting BootJarTool… 2009-02-02 15:10:30,920 INFO - Terracotta trunk-nightly, as of 20090201-170215 (Revision 11448 by [email protected] from trunk) 2009-02-02 15:10:31,352 INFO - Configuration loaded from the file at ‘/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml’. =========================================================================

JBoss Bootstrap Environment

JBOSS_HOME: /home/mruddy/jboss-eap-4.3/jboss-as

JAVA: /usr/java/bin/java

JAVA_OPTS: -d64 -Dprogram.name=run.sh -server -Xbootclasspath/p:/home/mruddy/terracotta-trunk-nightly-rev11448/lib/dso-boot/dso-boot-hotspot_solaris-x86_150_16.jar -Dtc.install-root=/home/mruddy/terracotta-trunk-nightly-rev11448 -Dtc.config=/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml

CLASSPATH: /home/mruddy/jboss-eap-4.3/jboss-as/bin/run.jar:/usr/java/lib/tools.jar

=========================================================================

2009-02-02 15:10:34,525 INFO - Terracotta trunk-nightly, as of 20090201-170215 (Revision 11448 by [email protected] from trunk) 2009-02-02 15:10:34,943 INFO - Configuration loaded from the file at ‘/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml’. 2009-02-02 15:10:35,035 INFO - Log file: ‘/home/mruddy/logs-192.168.103.73/terracotta-client.log’. java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.createGlobalContext(ClassProcessorHelper.java:593) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.initialize(ClassProcessorHelper.java:393) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$100(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) Caused by: com.tc.config.schema.setup.ConfigurationSetupException: ************************************************* Unknown Solaris architecture: (“os.arch” = amd64) *************************************************

    at com.tc.object.config.StandardDSOClientConfigHelperImpl.<init>(StandardDSOClientConfigHelperImpl.java:246)
    at com.tc.object.config.StandardDSOClientConfigHelperImpl.<init>(StandardDSOClientConfigHelperImpl.java:198)
    at com.tc.object.bytecode.hook.impl.DSOContextImpl.getGlobalConfigHelper(DSOContextImpl.java:208)
    at com.tc.object.bytecode.hook.impl.DSOContextImpl.createGlobalContext(DSOContextImpl.java:65)
    ... 18 more Caused by: com.tc.object.tools.UnsupportedVMException: Unknown Solaris architecture: ("os.arch" = amd64)
    at com.tc.object.tools.BootJarSignature.<init>(BootJarSignature.java:23)
    at com.tc.object.tools.BootJarSignature.getSignatureForThisVM(BootJarSignature.java:52)
    at com.tc.object.tools.BootJar.getBootJarForReading(BootJar.java:82)
    at com.tc.object.tools.BootJar.getDefaultBootJarForReading(BootJar.java:130)
    at com.tc.object.config.StandardDSOClientConfigHelperImpl.doAutoconfig(StandardDSOClientConfigHelperImpl.java:634)
    at com.tc.object.config.StandardDSOClientConfigHelperImpl.<init>(StandardDSOClientConfigHelperImpl.java:244)
    ... 21 more

Comments

Fiona OShea 2009-02-02

We want to a. Get rid of Stack trace and give clear error message b. Have the ability to turn the check off c. Make sure new error message describes how to turn check off

Verify new error message with PM

Mike Ruddy 2009-02-05

using the new terracotta-2.7.3 source and distro, i got this working. i’ll attach the source addition soon. also, below’s the contents of my tc-run.sh script. to run in 64-bit mode, it’s important to put “-d64” into the JAVA_OPTS before calling the dso-env.sh so that the boot jar gets created and DSO_BOOT_JAR set correctly: export JAVA_OPTS=”$JAVA_OPTS -d64” TC_INSTALL_DIR=/home/mruddy/terracotta-2.7.3 TC_CONFIG_PATH=/home/mruddy/jboss-eap-4.3/jboss-as/server/tc-config.xml . $TC_INSTALL_DIR/bin/dso-env.sh -q export JAVA_OPTS=”$TC_JAVA_OPTS $JAVA_OPTS” /home/mruddy/jboss-eap-4.3/jboss-as/bin/run.sh -b 0.0.0.0 -c axi01

Mike Ruddy 2009-02-05

diff of terracotta-2.7.3 version vs. the attached

21a21

private static final String OS_SOLARIS_AMD64 = “solaris-amd64”; 109c110,112 < } else { — } else if (“amd64”.equals(lowerCaseArch)) { return OS_SOLARIS_AMD64; } else {

Alex Miller 2009-02-05

Regarding the comment from DRB,

a) We can definitely print a clearer error message. Right now throwing an exception is the way this error is getting propagated back into the container. Should we exit the VM or something? Or just print an error message but throw no exception? If we did the latter, I think dso would be half-initialized.

b) I don’t think we can do that? We’re checking here that the boot jar matches the vm (and the boot jar is tagged with the os). Seems kind of dangerous to turn that off?

c) Sure, pending above.

Fiona OShea 2009-02-06

Fiona - create a new jira with DRB comments. this Jira should just cover Mike’s patch.

Fiona OShea 2009-02-06

I believe this is Ok to go in once Mike submits the contributor agreement, and after verification by Transparency team

Alex Miller 2009-02-16

From Tim M: “Just to confirm, we received Octavian Florescu’s contributor agreement via fax, so his code contribution is now “clean” and can be used.”

Hung Huynh 2009-03-05

applied the attached patch

nadeem ghani 2009-04-20

Verified patch is in; don’t have a AMD 64 bit machine to test