Jump to content
Excelsior Forums


  • Content count

  • Joined

  • Last visited

Everything posted by qqxx2000

  1. It appears I cannot attach the jar directly. So I zipped it. ThreadTest.zip
  2. We discovered a thread bug in our software that crashes JET VM. Basically a thread is trying to update Swing UI outside of the AWT event dispatch thread. Then JET reports: JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: runtime error at com/excelsior/jet/runtime/excepts/stacktrace/StackTrace.java:187 Unable to find method for call site 0x000000001336b50d (code segment 0x000000001336b480) in class java.util.Vector) But when we reproduce the bug with Java VM, the VM prints out stack traces as it should and does not crash. We will fix our bug but believe that the JET team should know this. The version information of the JET we are using: version info: jet-800-mp1 (pro, en) Java version: 1.6.0_43 Excelsior JET 8.00 Professional edition JET Profile: Java SE version: 1.6.0_43; JET update level: 11; CPU architecture: amd64 Runtime: Desktop Application was deployed
  3. We created a small test case that reproduces the bug. It turns out that only 64-bit JET has the problem. The test jar file is attached. To run with JVM directly: java -classpath ThreadTest.jar CopyItemsThreadTest Then you will see a dialog poping up and a series of exception stack traces printed in the console. But the dialog will stay open and functional after that. When compiling with JET 8.0 64-bit with all default settings, at the Test Run step, run the application and JET reports: --------------------------------------------------------------------------- Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 129 >= 1 JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: runtime error at com/excelsior/jet/runtime/excepts/stacktrace/StackTrace.java:187 Unable to find method for call site 0x000000001336b50d (code segment 0x000000001336b480) in class java.util.Vector) Please, contact Excelsior Support at <java@excelsior-usa.com>. Extra information about error is saved in the "jet_err_1300.txt" file. --------------------------------------------------------------------------- The application has terminated with exit code: 9 If you continue to compile it as EXE, run the exe and JET will report an error and exit. JET 8.0 32-bit does not have this problem.
  4. We are trying a workaround proposed in the following Java bug: (process) Runtime.exec() cannot invoke applications with unicode parameters (win) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4947220 The workaround uses environment variables to pass unicode argument strings to a process. It works in Java runtime. But it failed after we compiled the workaround with JET. We used JDK 1.6.0_u24 and various professional versions of JET including the latest 7.6 MP2. We used all default settings for JET project. I attached the source code of the test program that copies files to demonstrate the problem. When you run the program with Java Runtime directly, two "success" will be printed to the console. When you run the program with JET, you will get one "success" and one "fail". One thing we noticed that JET failed even at Step 2, "Perform a test run", with the uncompiled jar. Is there some settings in JET we overlooked? CopyFileTest.java
  5. qqxx2000

    64 bit JET

    Is there a plan for JET to support 64-bit Windows or Linux? We have increasing requests from people using huge data that cannot be loaded in 32-bit memory space. We successfully got our program to run on 64-bit Windows and Linux with Sun JRE. But we like to the performance gain from JET and also don't want to deliver the byte code directly.
  6. qqxx2000

    64 bit JET

    No, we haven't done any detailed cpu performance evaluation yet. Right now we mainly focus on solving the memory problem. So the difference between 32bit and 64bit for us is if the program can load the data or not. Our experiment on Linux 64bit didn't show noticeable performance loss though.
  7. I have a simple binary search method. It runs fine with JRE. But after I compile it with JET, the exe program runs in an infinite loop. In JRE: D:\>java JETTest 70==0,105.0==49.5,140==0 35==70,70.0==49.5,70==0 17==35,52.0==49.5,35==0 8==17,43.0==49.5,17==0 12==8,47.0==49.5,17==8 14==12,49.0==49.5,17==12 15==14,50.0==49.5,17==14 14==15,49.0==49.5,15==14 14 Run JET compiled exe, I got an infinite loop that keeps spitting out 8==0,43.0==49.5,17==0 The print-outs are just for debugging purpose to show the problem. I attached the source code below. I'm using JET v6.4 Professional Edition with Java SE 6 Update 7. I also tried the Maintenance Pack 1. It doesn't work either. I also tried to use all default settings to set up the JET project (also attached below). But it didn't help. ----------------------------------------- import java.awt.geom.Point2D; public class JETTest { public static int binarySearch(Point2D.Double p, double[] ms) { boolean found = false; int upperBound = ms.length - 1; int lowerBound = 0; int prevIndex = 0; while (!found) { int targetIndex = (upperBound + lowerBound) / 2; if (targetIndex == prevIndex) return targetIndex; double value = ms[targetIndex]; System.out.println(targetIndex+"=="+ prevIndex+","+value+"=="+p.getX()+","+upperBound +"=="+ lowerBound); System.out.flush(); if (value == p.getX()) return targetIndex; if (value > p.getX()) upperBound = targetIndex; else//else less lowerBound = targetIndex; prevIndex = targetIndex; } return 0; } public static void main(String[] args) { double[] ms = new double[] {35.0,36.0,37.0,38.0,39.0,40.0,41.0,42.0, 43.0,44.0,45.0,46.0,47.0,48.0,49.0,50.0,51.0,52.0, 53.0,54.0,55.0,56.0,57.0,58.0,59.0,60.0,61.0,62.0, 63.0,64.0,65.0,66.0,67.0,68.0,69.0,70.0,71.0,72.0, 73.0,74.0,75.0,76.0,77.0,78.0,79.0,80.0,81.0,82.0, 83.0,84.0,85.0,86.0,87.0,88.0,89.0,90.0,91.0,92.0, 93.0,94.0,95.0,96.0,97.0,98.0,99.0,100.0,101.0,102.0, 103.0,104.0,105.0,106.0,107.0,108.0,109.0,110.0, 111.0,112.0,113.0,115.0,117.0,118.0,119.0,120.0, 121.0,122.0,123.0,124.0,125.0,126.0,127.0,128.0, 129.0,130.0,131.0,133.0,134.0,135.0,137.0,139.0, 141.0,142.0,144.0,147.0,149.0,151.0,155.0,156.0, 159.0,160.0,161.0,163.0,165.0,177.0,179.0,181.0, 185.0,186.0,189.0,191.0,193.0,194.0,207.0,208.0, 209.0,210.0,216.0,218.0,219.0,220.0,237.0,251.0, 254.0,255.0,267.0,268.0,269.0,270.0,277.0,283.0,290.0}; int i = binarySearch(new Point2D.Double(49.5,49.5), ms); System.out.println(i); } } ----------------------- %%Excelsior JET v6.4 project file -compilewithfixedheap- -gendll- -genstackalloc+ -genstacktrace- -global- -gui- -ignoreclassduplication+ -ignorememberabsence+ -inline+ -splashgetfrommanifest- -classabsence=HANDLE -compilerheap=0 -heaplimit=0 -inlinelimit=100 -inlinetolimit=1000 -javacommandline:=java JETTest -jetcplastpage:=PageCompile -jetrt=Desktop -jetvmprop=-Djet.jit.fast -Djet.gc.heaplimit:0 -main=JETTest -outputdir=. -outputname=Untitled -stacklimit=900000 -startupprofile=./Untitled.startup !classpathentry . -pack=none -protect=all -optimize=all !end !module ./Untitled.usg
  8. qqxx2000

    Compiled Program runs in an infinite loop

    No, I haven't found other problems yet. Yes, I want to be able to search for potential problems to double check. After you told me the cause, I turned on the warnings when compiling with JET and got thousands of warnings about unreachable code. It is too many to search for unless there is a specific pattern. I guess I probably will ask for a hot fix. Thanks for the help.
  9. qqxx2000

    Compiled Program runs in an infinite loop

    Is there a way to turn off dead code elimination without turning off other optimization? I'm asking this because this method is a part of a large project worked by many people. So.. you know. This bug made me worried about potential problems else where.
  10. 1. I cannot reset After-install runnable field to empty in either original project or update project. This is especially a problem for update project. I have to set a do-nothing exe there. 2. When I ran the update package on a PC where the original package was not installed, In the step to choose installation location, the list was empty. So I selected a location. Then when I tried to select another location, the program said that the first location was automatically detected, which was not true. I did this test because we used a different installer before. I wanted to see if the update package can work with our old installation.
  11. I tried to create a update package but got this error: D:\Projects\Installer\JET Builder>xpack R1_9b2a__1.jpn JetPackII batch mode 0% filtering out compiled classes from charsets.jar 1% 2% 3% processing non-compiled classes from charsets.jar with pack200 7% 11% filtering out compiled classes from jsse.jar processing non-compiled classes from jsse.jar with pack200 12% Exception in thread "Thread-1" java.lang.NullPointerException at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) at java.lang.Void.<unknown>(Unknown Source) I worked around this by recreating the original package without Java SE API and then created the update package successfully since I know that there is no change in Java SE API. But it is kind inconvenient to maintain two pack projects.