Bugzilla – Full Text Bug Listing
| Summary: | Processor faults cause AUT to abort | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Adrian Price <adrianp.quatinus> | ||||
| Component: | TPTP | Assignee: | Torsten Stolpmann <stolpmann> | ||||
| Status: | ASSIGNED --- | QA Contact: | Torsten Stolpmann <stolpmann> | ||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | jgwest | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Thanks for your feedback Adrian. My impression is that you are simply tracing more allocations than the current profiler implementation is able to handle within the given memory limits. As cited in http://www.ibm.com/developerworks/rational/tutorials/profilingjavaapplicationsusingrad/profilingjavaapplicationsusingrad-pdf.pdf TPTP authors are discouraging memory tracing without giving strong filtering settings, especially while enabling allocation site details. The fact that raising your heap size above 3200m breaks the profiler indicates that your profiler process is hitting the OS limit at 4GB for the process containing your VM (it's a 32 Bit VM which is most probably running in a 32 Bit Process - hence the 4GB limit). The attached logs indicate as well that native memory allocations are failing. You might want to try the following to remedy this: - Be more conservative with you filters (including any of the above is a *lot* of allocations) - Running you AUT in a 64 Bit Java VM - Logging your Memory trace to a file instead of receiving the live events Hope this helps, Torsten Hello Torsten, Thank you for your helpful explanation and suggestions. What you say makes perfect sense - I will try again with more conservative settings. Best regards, --A |
Created attachment 206578 [details] Processor fault logs I have been trying to profile memory allocation (separately, and *without* allocation site details) for various combinations of org.eclipse.emf.* * INCLUDE, org.eclipse.wst.wsdl.* * INCLUDE, org.eclipse.xsd.* * INCLUDE, org.eclipse.swt.* * INCLUDE. In many cases the application under test terminates abruptly as a result of processor exceptions. Sometimes the fault occurs during class loading, other times it occurs in Martini code. FWIW I have noticed that raising the JVM max heap size above around 800m invariably results in premature termination of the AUT during the launch phase. In many cases I get the impression that the failure could be related to the generation of a large amount of profile data. As it is, I have had to set the IDE JVM to -Xmx3200m ! (any more than that seems to prevent the profiler from working at all). I have attached the processor fault logs. OS: Windows 7 SP1 (64-bit) AUT: JDK-1.6.0_029 (32-bit) IDE: Eclipse-3.6.2 + TPTP-4.7.2 on JDK-1.6.0_029 (64-bit)