Amplifier XE2013 Error 0x40000002 Insufficient memory Failed to finalize result

Amplifier XE2013 Error 0x40000002 Insufficient memory Failed to finalize result

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

47 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

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>

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.

>>...However it could be that I am missing a setting that allows the Amplifier to use more memory?..

Please verify Virtual Memory settings, that is, Min and Max values ( increase, for example, by 2x ), in [ Control Panel ] -> System -> Advanced -> Performance Settings

MsInfo32.exe also provides lots of details for memory and it would be nice if you post its report. Thanks in advance.

@Sonjuhi

Can you open the dump file with windbg and issue this command !analyze -v

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.  

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.

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

Peter,

I think the 2GB limitation could be resolved especially for a 32-bit application that runs on a 64-bit Windows platform. However, I'd like to understand why that approach ( to use as much as possible memory ) was selected for data collection?

Note: I'm dealing with a similar problem ( that is, 2GB limitation ) when doing linear algebra calculations with very large matricies on 32-bit Windows platforms.

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

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

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

Hi Peter,

are you refering to AWE?

Zitat:

iliyapolak schrieb:

Hi Peter,

Do you mean "large address space aware" flag?

Zitat:

iliyapolak schrieb:

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.

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

>>Should do "editbin.exe /LARGEADDRESSWARE 32bit_app.exe" to generate new one first.

Peter,

This is Not a universal solution ( I would say already obsolete ) and it can't be used on Windows 7 OSs. Then, it is Not enough to enable that option and OS should support that feature.

Why that solution is obsolete? Because all operating systems that support AWE almost at the end of life cycles of support by Microsoft.

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 another words it crashes )?

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

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

@Sergey

I must admit that I only now saw that Sonjuhi has 32-bit Windows so in this case usage of AWE on order to address more than 2GB makes sense.

>>I must admit that I only now saw that Sonjuhi has 32-bit Windows so in this case usage of AWE on order to
>>address more than 2GB makes sense.

It is absolutely Not clear that he has a 32-bit Windows operating system that supports AWE technology. Than, it is Not possible for the VTune to allocate more than 2GB of memory on any 32-bit Windows operating system without substantional code modifications. A linker option /LARGEADDRESSWARE does Not mean that more than 2GB of memory will be allocated as soon as it is enabled.

I think you've forgotten that at the end of 2012 I've spent significant amount of time on R&D related to AWE:

Forum Topic: Address Windowing Extensions ( AWE ) technology on Windows platforms with Intel CPUs
Web-link: software.intel.com/en-us/forums/topic/344931

and I've completed all needed tests on Windows Server 2003 32-bit operating system. Since AWE is Not a unuversal solution the project was cancelled. Current update is as follows:

There are at least four different methods which I'm currently considering that could allocate significantly more memory ( up to a Maximum value of Virtual Memory set for the 32-bit Windows XP or 64-bit Windows 7&8 ).

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.

>>...If the user still works on Win32, it is not helpful...

I think Microsoft really underestimated demands of modern Data Mining and Scientific applications.

>>...So I assume that Visual Studio consumed memory high (I don't know why and how)...

Visual Studios don't use lots of memory ( but a trend is alarming for latest versions because usage grows! ) and here are some real data ( just for reference on 32-bit Windows XP ):

VS 2005 PE - ~18MB + ~17MB ( VM )
VS 2008 EE - ~17MB + ~18MB ( VM )
VS 2010 EE - ~60MB + ~40MB ( VM )

PE - Professional Edition
EE - Express Edition

I have 8 different Visual C++ and Studios on a 64-bit Windows 7 Professional computer and let me know if you need memory usage numbers.

Hi Sergey,

I was talking about the 32-bit app running inside WOW64 on 64-bit Windows OS.I do not know the exact specification of @Sonjuhi system.Windows Internals book clearly states Wow64 process can allocate up to 4GB of memory if the compiled image has the large-address-aware flag set.As I said earlier you can use testlimit tool to verify this.

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

It would be interesting if thread's starter could reproduce the issue and measure the memory usage with process explorer or better with VMMap tool.This is needed to verify the amount of commited memory by VS.

. >>>Using /LARGEADDRESSWARE linker option OR using editbin.exe to regenerate executable is not helpful on Win32, BUT helpful on Win64>>>

Do you mean for 32-bit application compiled with /LARGEADDRESSAWARE flag?

>>>Do you mean for 32-bit application compiled with /LARGEADDRESSAWARE flag?>>

That is true, compiler with the flag on Win32 then run it on Win64.

Zitat:

Peter Wang (Intel) schrieb:

>>>Do you mean for 32-bit application compiled with /LARGEADDRESSAWARE flag?>>

That is true, compiler with the flag on Win32 then run it on Win64.

So it could benefit from large-address-aware flag.

The benefit is - build on Win32, run on Win64. 

Zitat:

Peter Wang (Intel) schrieb:

The benefit is - build on Win32, run on Win64. 

Yes I mean the ability to use 4GB of memory when running on Win64 OS.

>>...I was talking about the 32-bit app running inside WOW64 on 64-bit Windows OS...

Even if it runs inside of WoW64 on 64-bit Windows OS it is Not possible to allocate more than 2GB of memory ( Should I provide both of you a test case? ). Another thing is the /LARGEADDRESSAWARE option is Not a Compiler option and this is the Linker option ( take a look at MSDN for more information ).

>>>Even if it runs inside of WoW64 on 64-bit Windows OS it is Not possible to allocate more than 2GB of memory ( Should I provide both of you a test case? )>>>

Windows Internals book(6 edition part 1) clearly states that such process can allocate more than 2GB.In one of my previous posts I brought to your attention a link to article written by Mark Russinovich where he was able to allocate 4GB of memory with his 32-bit testlimit tool.I suggest you to test his tool.

>>...Windows Internals book(6 edition part 1) clearly states that such process can allocate more than 2GB...

A test case and a quote from the book, please (!) and I think it will be a significant blow up for Microsoft.

Everybody knows that it is Impossible to allocate more then 2GB of memory for a regular 32-bit application without using AWE technology and a right operating system that supports it.

Unfortunately, I see that you constantly referring to some books, links, etc and do not provide any real C/C++ codes that prove your statements. Do you have a Visual Studio? Do you have a standalone C/C++ compiler? Let me know and I'll provide you a C/C++ test case ( tuned for your development environment ) that demonstartes that 2GB is the Limit for a regular 32-bit application.

Here is a zip file with 3 test projects.

Anlagen: 

AnhangGröße
Herunterladen awetestapp.zip10.11 KB

>>>A test case and a quote from the book, please (!) and I think it will be a significant blow up for Microsoft.>>>

Have you read that book?Do you know that "Windows Internals" is the most comprehensive source of knowledge about the OS implementation(without source code).It is written by people which obviously had access to Windows source code.

Quote from the book on page 224."WoW64 Process Address Space Layout"

WoW64 processes can run with 2GB or 4GB of virtual space.If the image header has the large-address-aware flag set, the memory manager reserves the user-mode address space above the 4-GB boundary through the end of user mode boundary. This is the quote taken directly from the book.Sadly there is no any test cases.How do you understand the quote above?

>>>Everybody knows that it is Impossible to allocate more then 2GB of memory for a regular 32-bit application without using AWE technology and a right operating system that supports it.>>>

I replied in my previous post with the link from MSDN where was written than 64-bit Win do not use PAE.Btw AWE is based on PAE. Here is the link /msdn.microsoft.com/en-us/library/windows/hardware/gg487508.aspx

The excerpt from the official Microsoft site:

Physical Address Extension. PAE is an Intel-provided memory address extension that enables support of up to 64 GB of physical memory for applications running on most 32-bit (IA-32) Intel Pentium Pro and later platforms. Support for PAE is provided under Windows 2000 and 32-bit versions of Windows XP and Windows Server 2003. 64-bit versions of Windows do not support PAE. PAE allows the most recent IA-32 processors to expand the number of bits that can be used to address physical memory from 32 bits to 36 bits through support in the host operating system for applications using the Address Windowing Extensions (AWE) application programming interface (API)

Btw AWE is not the same as large-address-memory.

>>>Unfortunately, I see that you constantly referring to some books, links, etc and do not provide any real C/C++ codes>>>

I think that those sources are very relevant to our discussion.

>>>Let me know and I'll provide you a C/C++ test case ( tuned for your development environment ) that demonstartes that 2GB is the Limit for a regular 32-bit application>>>

Please download and run 32-bit version of testlimit tool on Win 64-bit and post the console output about the max allocated memory.

Here is the another excerpt from the M.Russinovich article:

Because the address space on 64-bit Windows is much larger than 4GB, something I’ll describe shortly, Windows can give 32-bit processes the maximum 4GB that they can address and use the rest for the operating system’s virtual memory. If you run Testlimit on 64-bit Windows, you’ll see it consume the entire 32-bit addressable address space:

>>>Here is a zip file with 3 test projects.>>>

Tomorrow at my job I will run your code(my HDD died and I'm using Linux live disc).

>>...WoW64 processes can run with 2GB or 4GB of virtual space...

This is a different thing and for the second day we're taking about allocation of memory Not mapping to an address space of the system!

When malloc, or calloc, or VirtualAlloc, etc, functions are called in a 32-bit application that runs on a 32-bit Windows or 64-bit Windows it is Not Possible to Allocate ( did you see that I stressed importance of it? ) more than 2GB of memory.

This is how Microsoft designed the 32-bit environment many-many years ago and when some demand for more memory was needed ( by software companies, data mining applications, etc ) then Microsoft designed and implemented the AWE to extend that limit to 3GB.

Do you see the difference in my next statement? That is, 4GB address space is mapped to a 32-bit application and only 2GB of memory could be allocated out of 4GB?

Once again, Do you have a Visual Studio? Do you have a standalone C/C++ compiler? Please do your own programming / tests and then report results because I clearly see that you did not verify it and continue to quote from different sources.

Ask Microsoft if it is possible to allocate more than 2GB of memory for a regular 32-bit application.

@Sergey

AWE is based on hardware PAE and is used to allocate more than 4GB of memory for 32-bit application.AWE is not used to implement large-address-aware. >>>

Ask Microsoft if it is possible to allocate more than 2GB of memory for a regular 32-bit application.>>>

32-bit app which runs on Win64 OScan be given 4GB of memory and there is no need to any AWE in order to implement this. Few times I asked you to test such a allocation with testlimit tool which can allocate 4GB of memory.

>>>Once again, Do you have a Visual Studio>>>

My HDD failed I'm using live disc , cannot write any code.

>>>That is, 4GB address space is mapped to a 32-bit application and only 2GB of memory could be allocated out of 4GB?>>>

Testlimit tool alocated 4GB of memory while running on Win 64-bit OS.

>>>then Microsoft designed and implemented the AWE to extend that limit to 3GB.>>>

Actually AWE was designed to enable an application to allocate more than 4GB of memory.3GB limit is managed by memory manager where OS kernel and system paged pool is given 1GB of memory and user mode process is given 3GB and this is not AWE.

>>...My HDD failed I'm using live disc , cannot write any code.

Iliya, I really need to talk with you and I will send you a private email and let's stop that discussion. Thanks in advance.

Ok Sergey I'm not interested in continuation of this discussion.

>>...So I assume that Visual Studio consumed memory high (I don't know why and how)...

Peter, I don't think that this is the root cause of the problem. Here are some additional data for different Visual Studios on Windows 7 Professional:

Visual Studio 2012 Express Windows Desktop - ~103MB + ~99MB ( VM )
Visual Studio 2010 Shell with Parallel Studio XE 2013 - ~116MB + ~118MB ( VM )
Visual Studio 2010 Express Windows Phone - ~106MB + ~112MB ( VM )
Visual C++ 2010 Express - ~99MB + ~107MB ( VM )
Visual Studio 2008 Professional - ~38MB + ~30MB ( VM )
Visual Studio 2005 Professional - ~25MB + ~21MB ( VM )
Visual C++ 6.0 Enterprise - ~16MB + ~7MB ( VM )
Visual C++ 4.2 Enterprise - ~15MB + ~7MB ( VM )

Even in the worst case ( ~116MB + ~118MB ( VM ) ) ~1.6GB are not used and it can't applicable anyway because VTune uses its own address space and doesn't share the address space with a Visual Studio.

Interesting what is the memory usage of non express edition of Visual Studio?

>>...what is the memory usage of non express edition of Visual Studio?

>>...
>>Visual Studio 2010 Shell with Parallel Studio XE 2013 - ~116MB + ~118MB ( VM )
>>...
>>Visual Studio 2008 Professional - ~38MB + ~30MB ( VM )
>>Visual Studio 2005 Professional - ~25MB + ~21MB ( VM )
>>...

Sergey

I mean full version like VS2010 Ultimate.

Thanks .

>>...I mean full version like VS2010 Ultimate...

I don't know because I never used it. I expect that memory usage of VS 2010 Ultimate could be even higher then numbers in my previous post.

Zitat:

Sergey Kostrov schrieb:

>>...I mean full version like VS2010 Ultimate...

I don't know because I never used it. I expect that memory usage of VS 2010 Ultimate could be even higher then numbers in my previous post.

Probably yes because of added functionality.

>>5. crash-reports
>>
>>Please see attached.

Peter, Have you seen these reports? Where are they?

>>>Thank you everyone, for your responses and help on this issue. This issue now seems to be resolved>>>

It seems that his issue is resolved.

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen