Java mks api crash

Question

Story: I try to connect to integrity with the java mks api and then to execute "si viewsandbox" command. The connection to integrity and execution of the command works fine until when I try it with tiny sandboxes. If I try the viewsandbox command with a huge sandbox, I get the following error log:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00000000, pid=4984, tid=3628
#
# JRE version:  (7.0_40-b43) (build )
# Java VM: Java HotSpot(TM) Client VM (24.0-b56 mixed mode windows-x86 )
# Problematic frame:
# C  0x00000000
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x0054dc00):  JavaThread "main" [_thread_in_Java, id=3628, stack(0x010a0000,0x10aa0000)]

siginfo: ExceptionCode=0xc0000005, ExceptionInformation=0x00000008 0x00000000

Registers:
EAX=0x00100000, EBX=0x52aada90, ECX=0x12aa0da0, EDX=0x00500001
ESP=0x10a9edf0, EBP=0x10a9ee18, ESI=0x10a9edf4, EDI=0x10a9ee1c
EIP=0x00000000, EFLAGS=0x00010216

Top of Stack: (sp=0x10a9edf0)
0x10a9edf0:   10aa347b 12aa0da0 10a9edf8 52ab76ab
0x10a9ee00:   10a9ee1c 52b0d648 00000000 52ab76e8
0x10a9ee10:   10a9edf4 10a9ee20 10a9ee3c 10aa03d7
0x10a9ee20:   10a9ee70 10a9ee4c 639be6e2 00001f80
0x10a9ee30:   10aa0372 0054dc00 52ab76e8 10a9eebc
0x10a9ee40:   639bee1a 10a9ee70 10a9ef44 0000000a
0x10a9ee50:   52ab76e8 10aa9800 10a9ef54 00000000
0x10a9ee60:   0054dc00 0054dc00 0054dc00 00000004 

Instructions: (pc=0x00000000)
0xffffffe0:   


Register to memory mapping:

EAX=0x00100000 is an unknown value
EBX=0x52aada90 is an oop
{method} 
 - klass: {other class}
ECX=0x12aa0da0 is an oop
java.lang.Class 
 - klass: 'java/lang/Class'
EDX=0x00500001 is an unknown value
ESP=0x10a9edf0 is pointing into the stack for thread: 0x0054dc00
EBP=0x10a9ee18 is pointing into the stack for thread: 0x0054dc00
ESI=0x10a9edf4 is pointing into the stack for thread: 0x0054dc00
EDI=0x10a9ee1c is pointing into the stack for thread: 0x0054dc00


Stack: [0x010a0000,0x10aa0000],  sp=0x10a9edf0,  free space=255995k

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
=>0x0054dc00 JavaThread "main" [_thread_in_Java, id=3628, stack(0x010a0000,0x10aa0000)]

Other Threads:
  0x56e40c00 VMThread [stack: 0x57060000,0x570b0000] [id=5364]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
 def new generation   total 157248K, used 2795K [0x12aa0000, 0x1d540000, 0x27ff0000)
  eden space 139776K,   2% used [0x12aa0000, 0x12d5ae88, 0x1b320000)
  from space 17472K,   0% used [0x1b320000, 0x1b320000, 0x1c430000)
  to   space 17472K,   0% used [0x1c430000, 0x1c430000, 0x1d540000)
 tenured generation   total 349568K, used 0K [0x27ff0000, 0x3d550000, 0x52aa0000)
   the space 349568K,   0% used [0x27ff0000, 0x27ff0000, 0x27ff0200, 0x3d550000)
 compacting perm gen  total 12288K, used 518K [0x52aa0000, 0x536a0000, 0x56aa0000)
   the space 12288K,   4% used [0x52aa0000, 0x52b21aa8, 0x52b21c00, 0x536a0000)
No shared spaces configured.

Card table byte_map: [0x56aa0000,0x56cd0000] byte_map_base: 0x56a0ab00

Polling page: 0x001c0000

Code Cache  [0x10aa0000, 0x10ae8000, 0x12aa0000)
 total_blobs=39 nmethods=0 adapters=18 free_code_cache=32499Kb largest_free_block=33278912

Compilation events (0 events):
No events

GC Heap History (0 events):
No events

Deoptimization events (0 events):
No events

Internal exceptions (0 events):
No events

Events (10 events):
Event: 0.015 loading class 0x00b0bd30 done
Event: 0.015 loading class 0x00b0bd10 done
Event: 0.015 loading class 0x00b16d50
Event: 0.015 loading class 0x00b16d50 done
Event: 0.015 loading class 0x00b13e28
Event: 0.015 loading class 0x00b13e28 done
Event: 0.015 loading class 0x00b1af98
Event: 0.015 loading class 0x00b1af98 done
Event: 0.015 loading class 0x00b1afc0
Event: 0.015 loading class 0x00b1afc0 done


Dynamic libraries:
0x002e0000 - 0x0030f000  C:\Program Files\Integrity\IntegrityClient\jre\bin\java.exe
0x77090000 - 0x77210000  C:\Windows\SysWOW64\ntdll.dll
0x754b0000 - 0x755c0000  C:\Windows\syswow64\kernel32.dll
0x76c40000 - 0x76c87000  C:\Windows\syswow64\KERNELBASE.dll
0x76710000 - 0x767b0000  C:\Windows\syswow64\ADVAPI32.dll
0x76b90000 - 0x76c3c000  C:\Windows\syswow64\msvcrt.dll
0x74f60000 - 0x74f79000  C:\Windows\SysWOW64\sechost.dll
0x74c10000 - 0x74d00000  C:\Windows\syswow64\RPCRT4.dll
0x74bb0000 - 0x74c10000  C:\Windows\syswow64\SspiCli.dll
0x74ba0000 - 0x74bac000  C:\Windows\syswow64\CRYPTBASE.dll
0x764c0000 - 0x765c0000  C:\Windows\syswow64\USER32.dll
0x74d00000 - 0x74d90000  C:\Windows\syswow64\GDI32.dll
0x765c0000 - 0x765ca000  C:\Windows\syswow64\LPK.dll
0x75350000 - 0x753ed000  C:\Windows\syswow64\USP10.dll
0x73300000 - 0x7349e000  C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll
0x75420000 - 0x75477000  C:\Windows\syswow64\SHLWAPI.dll
0x74f00000 - 0x74f60000  C:\Windows\system32\IMM32.DLL
0x75280000 - 0x7534c000  C:\Windows\syswow64\MSCTF.dll
0x74880000 - 0x748c6000  C:\PROGRA~2\Sophos\SOPHOS~1\SOPHOS~1.DLL
0x76230000 - 0x76235000  C:\Windows\syswow64\PSAPI.DLL
0x65810000 - 0x658ce000  C:\Program Files\Integrity\IntegrityClient\jre\bin\msvcr100.dll
0x63880000 - 0x63c00000  C:\Program Files\Integrity\IntegrityClient\jre\bin\client\jvm.dll
0x6c600000 - 0x6c607000  C:\Windows\system32\WSOCK32.dll
0x76b50000 - 0x76b85000  C:\Windows\syswow64\WS2_32.dll
0x77060000 - 0x77066000  C:\Windows\syswow64\NSI.dll
0x73500000 - 0x73532000  C:\Windows\system32\WINMM.dll
0x6f8b0000 - 0x6f8bc000  C:\Program Files\Integrity\IntegrityClient\jre\bin\verify.dll
0x6f890000 - 0x6f8b0000  C:\Program Files\Integrity\IntegrityClient\jre\bin\java.dll
0x6f870000 - 0x6f883000  C:\Program Files\Integrity\IntegrityClient\jre\bin\zip.dll
0x6c510000 - 0x6c5fb000  C:\Windows\system32\dbghelp.dll

VM Arguments:
jvm_args: -Xss250M -Xms512M -Xmx1G 
java_command: C:\_projects\jenkins\run_and_log\MKS_connect_no_gui\mks_connect_test.jar C:/_projects/jenkins/DEV_m6.54.0.3/project.pj muell.txt
Launcher Type: SUN_STANDARD

I seek the solution for two weeks in any forums but with no success. I am almost to freak out -.-

Does anyone know what the problem could be?

I forgot to mention that the program runs as jarfile if this is an important aspect.

EDIT: When I set -XX:PermSize100M -Xss250M -Xms512M -Xmx1G then I get the following Exception:

com.mks.api.response.CommandException: mks.frame.app.ui.ViewException

What does this mean?

Answer 1

-XX:PermSize specifies the initial size that will be allocated during startup of the JVM. If necessary, the JVM will allocate up to -XX:MaxPermSize so try changing these values to greater values as -XX:PermSize=512 -XX:MaxPermSize=712

click here to get more info

Answer 2

That is an access violation in the JVM code, detected by the OS. The app may be involved, but you need to raise this with PTC (the company that now owns the MKS product suite) support. There isn't a lot that can be done in isolation because this report is going to look like a lot of other different reports. If there is a bug in the VM, then any number of conditions, environments, and byte-code could trigger it.

If you can't raise this with PTC, then you can experiment with switching the JRE. Source Integrity uses its own private JRE installed to /jre (you can see this in the stack trace) so you could easily drop a bug-fix release of the JRE next to /jre, rename the old one to /jre_old and the new one to /jre and it should pick up the new one. I think this is all you have to do, but it's been a long time since I've worked with the product.

Needless to say, this is not supported by PTC, etc., etc. but it is a data point.

Now, since one of the data points you have is that this is only triggered when the heap is allowed to grow to some large size, and I know large sandboxes will put a fair amount of pressure on the heap, you could even be running into a hardware problem. That is, this could be as simple as a bad stick of memory. Though rare these days, I've seen it before, and most of the time we rarely exercise memory resources to the extent that a a serious Java app can.

Furthermore, this appears to be a 32-bit JVM, which means the heap is going to be very constrained. The way process memory is segmented on Windows, we used to be able to just barely set the heap over 1Gb, depending on the sizes of the native libraries that have to coexist in the same process memory, the number of threads, and the permgen space. You may just be hitting a process memory limit.

Full disclosure: I used to work for MKS.

Answer 3

In the past I have the same issues and solved with the following approach

According to Integrations Builder Guide from MKS Integrity 2009 SP, ... when a command has the potential of returning a large number of work items ow work items with large amounts of information, consider using approach described in "Using Interim Responses"

To use interim response for the Java API execute the command using executeWithInterim() method and start reading work items from the response using the WorkItemIterator