Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 363154 - Processor faults cause AUT to abort
Summary: Processor faults cause AUT to abort
Status: ASSIGNED
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: TPTP (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows 7
: P3 blocker (vote)
Target Milestone: ---   Edit
Assignee: Torsten Stolpmann CLA
QA Contact: Torsten Stolpmann CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-08 06:25 EST by Adrian Price CLA
Modified: 2016-05-05 10:58 EDT (History)
1 user (show)

See Also:


Attachments
Processor fault logs (52.41 KB, application/zip)
2011-11-08 06:25 EST, Adrian Price CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Price CLA 2011-11-08 06:25:37 EST
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)
Comment 1 Torsten Stolpmann CLA 2011-11-14 09:23:41 EST
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
Comment 2 Adrian Price CLA 2011-11-19 15:15:04 EST
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