- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello experts,
I am evaluating Parallel Studio XE 2013 update 2 to see if this software could be useful for our software development needs. On most runs it crashes with message "Failed to finalize the result - Error 0x40000002 (Insufficient memory)". Here is what I see in the output window.
The database has been cleared, elapsed time is 0.436 seconds.
Raw data has been loaded to the database, elapsed time is 21.130 seconds.
Data transformations have been finished, elapsed time is 2.387 seconds.
Precomputing frequently used data has been finished, elapsed time is 0.011 seconds.
Finalizing the result took 24.252 seconds.
Sometimes, but not all the time, when I use the "Re-resolve" option it recovers and displays all the results ok. I am pretty sure that my machine has enough available memory. However it could be that I am missing a setting that allows the Amplifier to use more memory? Any help with this will be appreciated. Please let me know if you need more information.
Thank you,
SK
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
1. I'm not sure if the problem can be reproduced in latest VTune(TM) Amplifier XE 2013 Update 5
2. Did you run application with this tool in 32bit system? If this is the case, only 2GB memory space can be used for your app and the tool.
3. Is there same problem when collecting data in command line?
4. If you specified duration to reduce the result size, no insuffcient memory warning?
5. If the problem persists on latest version, please do
a) amplxe-feedback -create-bug-report <report archive>
b) amplxe-feedback -send-crash-report <report archive>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Sonjuhi
Can you open the dump file with windbg and issue this command !analyze -v
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for replying, Peter. Please see my responses to your questions below.
1. I'm not sure if the problem can be reproduced in latest VTune(TM) Amplifier XE 2013 Update 5
I upgraded to VTune(TM) Amplifier XE 2013 Update 5. The issue still exists.
2. Did you run application with this tool in 32bit system? If this is the case, only 2GB memory space can be used for your app and the tool.
It is a 32 bit system. Therefore this could be a limiting factor. My application does not use anywhere close to 2GB of memory though.
3. Is there same problem when collecting data in command line?
No, it seems to always work ok when I use the Command Line Interface.
4. If you specified duration to reduce the result size, no insuffcient memory warning?
Smaller data size (~ 2 minutes) almost always goes through. Slightly larger duration (~ 5 minutes) always crashes.
5. crash-reports
Please see attached.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If used smaller data set it worked but larger data set failed, I guess that memory usage (profiled data) was growing quickly. Even application does not exceed 2GB, because you ran long time, so result (raw data) was bigger and failed on finalizing. Serge is right! enlarging virtual memory space might be helpful in system32.
Other considerations are to do: 1) use "-data-limit" to avoid huge data process in finalizing 2) start from paused mode, and resume data collection in critical code area.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you everyone, for your responses and help on this issue. This issue now seems to be resolved; I haven’t seen it occur so far on several runs with long durations. Some of the symbol files associated with my application were either not properly loaded or were corrupted. I manually reloaded them, and everything seems to work ok.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>I think the 2GB limitation could be resolved especially for a 32-bit application that runs on a 64-bit Windows platform>>>
32-bit application running on 64-bit Windows will use up to 4GB of memory.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>3. Is there same problem when collecting data in command line? No, it seems to always work ok when I use the Command Line Interface.>>>
Maybe Visual Studio integration mode & standalone app consumed more memory than command line.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>32-bit application running on 64-bit Windows will use up to 4GB of memory>>>
Should do "editbin.exe /LARGEADDRESSWARE 32bit_app.exe" to generate new one first.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Peter,
are you refering to AWE?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
iliyapolak wrote:
Hi Peter,
Do you mean "large address space aware" flag?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
iliyapolak wrote:
Quote:
iliyapolakwrote:
Hi Peter,
Do you mean "large address space aware" flag?IIRC there is a testlimit tool which can test memory allocation on 32 and 64 bit versions of Windows.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>>32-bit application running on 64-bit Windows will use up to 4GB of memory>>> >>>This is wrong and I see that you really don't have any practical experience with AWE.>>>
@Sergey
The sentence questioned by you is directly taken from the article written by Windows Internals expert Mark Russinovich. Please read this link://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
AWE is based on PAE technology and Win 64-bit version do not support PAE. Please read this article ://msdn.microsoft.com/en-us/library/windows/hardware/gg487508.aspx
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>>My question was why does VTube use ~1.9GB of memory in some cases and stops collecting data as soon that limit is reached>>> In order to test 32-bit application memory allocation on 64-bit system I would advise to use testlimit tool.Regarding VTune crash is there any dump file which can provide any clue to the failed ip?
Here is another links which points to Microsoft article about the 32-bit application running inside Win 64-bit version.That article clearly states that application can allocate 4GB when compiled with large-address-aware flag.In such a case WOW64 process is responsible for the allocation.
//support.microsoft.com/default.aspx?scid=889654
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have to clarify:
1. Using /LARGEADDRESSWARE linker option OR using editbin.exe to regenerate executable is not helpful on Win32, BUT helpful on Win64. The benefit is that developer worked on Win32 and now plan to run application with VTune on Win64 (consider that VTune will consume extra memory besides application itself) - no source code change is required. If the user still works on Win32, it is not helpful
2. I don't know why this user ran out of memory on GUI - but I was told command line was OK. So I assume that Visual Studio consumed memory high (I don't know why and how), and using command line is a workaround.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page