2

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?

BumbleBeeX6
  • 29
  • 3
  • i don't know the product, just a few ideas: did you try it on different machines? with different java versions? what about the support at ptc? did you open a call there? – chris Jun 03 '15 at 07:27
  • hi, I tried the programm with several machines, but I always get the same error. The weird thing is that the code works with tiny sandboxes but not with huge one´s. At first, I thought that it is an memory or stack problem. So I set the memory to 1gb and the stack to 50mb (-Xmx1024M and -Xss50M) as an exmaple (tried differd values). – BumbleBeeX6 Jun 03 '15 at 07:50
  • Just a try to get any further: Are there any logfiles we can discuss about? can you start the app in a console window? use java.exe, not javaw.exe to get console output. Maybe edit `C:\Program Files\Integrity\IntegrityClient\jre\lib\logging.properties` to create some logfile. The content of processor registers at crash time is not that helpful... – chris Jun 03 '15 at 07:58
  • That is the output from the console. We know that the error depents on the "si viewsandbox" command and the number of members of the sandbox. It is weird that the app works with tiny sandboxes, but not with huge one. – BumbleBeeX6 Jun 03 '15 at 10:54

3 Answers3

1

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.

  • Thank you for your answer. I will try to change the java environment and the other suggestions from you :) . I will post a comment if something has changed. – BumbleBeeX6 Jun 05 '15 at 07:48
0

-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

Community
  • 1
  • 1
prudviraj
  • 3,634
  • 2
  • 16
  • 22
0

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

vasilenicusor
  • 2,023
  • 1
  • 21
  • 37
  • This assumes they are using their own app that hooks into the MKS API, not the shipped client, no? The client does not actually use the public API, which assumes there is no client to cache local state. It is the full client JVM errroring out completely here, possibly because of memory pressure, but we really don't know. Anyway, this brings back memories of actually writing code that /does/ use the public API. Sometimes in COBOL, no less... –  Jul 21 '15 at 16:27
  • keep in mind that mks has also an C API which i guess is more efficient regarding to memory consumption. I don't know how is the implementation of client, what I'm sure is the client can work fine with big projects - but because of java, exist at least one project which will make the client to crash ( .... java Lang error .....) – vasilenicusor Jul 21 '15 at 16:38
  • There are actually very specific corner cases with large projects (with and without many subprojects) that were /traditionally/ pain points with the client. These pain points usually manifested as memory related slowdowns and runtime exceptions. I recall it was partially because of how the client was caching sandbox metadata (which neither public API really has to manage). It was rare that specific metadata, when read, would cause a Java error or runtime, but it did happen. –  Jul 21 '15 at 19:06