Java mks api 崩溃答案

【问题标题】：Java mks api crashJava mks api 崩溃
【发布时间】：2015-08-17 06:13:54
【问题描述】：

故事：我尝试使用 java mks api 连接到完整性，然后执行“si viewsandbox”命令。与命令的完整性和执行的连接工作正常，直到我使用小型沙箱进行尝试。如果我尝试使用巨大沙箱的 viewsandbox 命令，我会收到以下错误日志：

#
# 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

我在任何论坛中寻求解决方案两周，但没有成功。我差点吓坏了-.-

有谁知道问题出在哪里？

如果这是一个重要方面，我忘了说程序作为 jarfile 运行。

编辑：当我设置 -XX:PermSize100M -Xss250M -Xms512M -Xmx1G 然后我得到以下异常：

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

这是什么意思？

【问题讨论】：

我不了解产品，只是一些想法：您是否在不同的机器上尝试过？有不同的java版本？ PTC 的支持情况如何？你在那里打过电话吗？
嗨，我用几台机器尝试了这个程序，但我总是得到同样的错误。奇怪的是，该代码适用于小型沙箱，但不适用于大型沙箱。起初，我以为是内存或堆栈问题。因此，我将内存设置为 1gb，堆栈设置为 50mb（-Xmx1024M 和 -Xss50M）作为示例（尝试了不同的值）。
只是尝试进一步了解：有没有我们可以讨论的日志文件？您可以在控制台窗口中启动应用程序吗？使用 java.exe，而不是 javaw.exe 来获取控制台输出。也许编辑C:\Program Files\Integrity\IntegrityClient\jre\lib\logging.properties 来创建一些日志文件。崩溃时处理器寄存器的内容没有那么有用...
这是控制台的输出。我们知道错误取决于“si viewsandbox”命令和沙箱成员的数量。奇怪的是，该应用程序适用于小型沙箱，但不适用于大型沙箱。

标签： java crash-reports mks-integrity

【解决方案1】：

过去我也有同样的问题，用下面的方法解决了

根据 MKS Integrity 2009 SP 的 Integrations Builder Guide，... 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"

要使用 Java API 的临时响应，请使用 executeWithInterim() 方法执行命令并使用 WorkItemIterator 开始从响应中读取工作项

【讨论】：

这假设他们使用自己的应用程序连接到 MKS API，而不是交付的客户端，不是吗？客户端实际上并不使用公共 API，它假定没有客户端来缓存本地状态。这是完整的客户端JVM在这里完全出错，可能是因为内存压力，但我们真的不知道。无论如何，这会让人想起实际编写/确实/使用公共 API 的代码。有时在 COBOL 中，同样如此......
请记住，mks 还有一个 C API，我猜它在内存消耗方面更有效。我不知道客户端的实现如何，我确定客户端可以在大型项目中正常工作 - 但是由于 java，至少存在一个会使客户端崩溃的项目（ .... java语言错误.....)
实际上存在非常具体的大型项目（有或没有很多子项目）的极端案例，这些案例是/传统上/客户的痛点。这些痛点通常表现为内存相关的减速和运行时异常。我记得这部分是因为客户端如何缓存沙盒元数据（公共 API 都不需要管理）。读取特定元数据时很少会导致 Java 错误或运行时，但它确实发生了。

【解决方案2】：

这是由操作系统检测到的 JVM 代码中的访问冲突。可能涉及应用程序，但您需要通过 PTC（现在拥有 MKS 产品套件的公司）的支持提出此问题。没有太多可以单独完成的事情，因为这份报告看起来会像很多其他不同的报告一样。如果 VM 中存在错误，那么任何数量的条件、环境和字节码都可能触发它。

如果您无法通过 PTC 提出此问题，那么您可以尝试切换 JRE。 Source Integrity 使用自己安装到 /jre 的私有 JRE（您可以在堆栈跟踪中看到这一点），因此您可以轻松地将 JRE 的错误修复版本放在 /jre 旁边，将旧版本重命名为 /jre_old 和新版本到 /jre，它应该会选择新的。我认为这就是你所要做的，但是我已经很久没有使用这个产品了。

不用说，PTC等不支持，但它是一个数据点。

现在，由于您拥有的一个数据点是，这仅在允许堆增长到较大大小时才会触发，而且我知道大型沙箱会对堆施加相当大的压力，您甚至可以遇到硬件问题。也就是说，这可能就像记忆棒一样简单。虽然这些天很少见，但我以前见过它，而且大多数时候我们很少像一个严肃的 Java 应用程序那样使用内存资源。

此外，这似乎是一个 32 位 JVM，这意味着堆将受到很大限制。进程内存在 Windows 上的分段方式，我们过去只能勉强将堆设置为超过 1Gb，这取决于必须共存于同一进程内存中的本机库的大小、线程数和永久空间.您可能只是达到了进程内存限制。

完全披露：我曾经为 MKS 工作。

【讨论】：

感谢您的回答。我会尝试改变java环境和你的其他建议:)。如果有什么变化，我会发表评论。

【解决方案3】：

-XX:PermSize 指定将在 JVM 启动期间分配的初始大小。如有必要，JVM 最多会分配 -XX:MaxPermSize，因此请尝试将这些值更改为更大的值，例如 -XX:PermSize=512 -XX:MaxPermSize= 712

click here to get more info

【讨论】：