Premature Operation end

[Salvatore_Li_Mandri]

HI,

I have been using XE Amplifier and XE Inspector 2013 for a while quite successfully, and with either tools lately I enter the [Finalize] tool's program phase on their own prior I executed the section of code I am interested to test (Using latest updates - I just comfirmed this)

The application runs quite well on its own - Either tool reports no error that I can tell

I read from another thread, that the operation I described is no related to memory issues because otherwise the Finalize phase would not complete. Any Idea?

Thanks

Sal

[David_A_Intel1]

Have you configured Amplifier XE to launch a script that launches your application?  Which OS are you running the tools on?

[Salvatore_Li_Mandri]

Hello,

I lunched the tool from inside Visual Sutudio IDE (VS2012) Update 2, at first

Retried even with with XE Inspector 2011 - Update 10 from inside VS2005 with same results, since my App is been converted to run in VS2012

Running in Window7 on a machine that uses Xeon E5-2609 (8 cores) w/16GB memory. The app  to test uses MFC (old code) and for testing must communicate with a 64 Bits App (native) tested successfully with XE 2013 from inside VS2012, that for the testing is running stand alone

Thanks - Sal

[David_A_Intel1]

okay, thanks.  what kind of app is it?  C#, C++, etc.?

Did you try running Amplifier XE standalone GUI and profiling your app?

Finally, you say it used to work, what changed?

[Salvatore_Li_Mandri]

Thanks for the replay,

1: It is a C++ application developed in VS2005, using MFC (it was developed long before .NET was invented) and it is been migrated to VS2012 as time permit

2: When I run the XE 2013 amplifier stand alone IDE tool (in Concurrency mode) and without involving the MS Visual Studio, the application at least completes initialization at it is appears on the screen. It closes after few mouse action clicks on the menu bar. When I run from VS the application closes before it appears for the first time on the screen. The application is fully operational as I said if it is run from MS Visual Studio Debug environment or by its-self.

3: The application has been expanded with new features - They are all operational - I would like to improve the performance of the application using your tool, since the application finally passed the XE Inspector 2011 and 2013

Regards, Sal

[David_A_Intel1]

Okay, so let's stick with the Hotspots analysis type, since it is the most basic *and* you can actually get concurrency info from it, as well.  Does it run to completion with Hotspots?

If you examine your project properties in the standalone Amplifier XE, is the "Automatically stop collection after (sec):" option selected?  Where are you storing the results from Amplifier XE?  Is it possible you are running out of disk space?  Is the working directory set correctly?

Does your application, by chance, launch multiple processes and then the original process terminates will the rest perform the functionality of the application?  Maybe you can describe the sequence of events from application start to profiling termination?  Are you terminating any processes, or anything that the profiler might intercept and misinterpret?

[Salvatore_Li_Mandri]

Hello again,

Run tool on its own outside VS

Tried Hot Spot - It works, with no signs of any early termination

Tried again Concurrency - It fails as I reported

Examined Project properties - No controlis checked about limiting the testing execution duration (the one you mentioned)

The application once it starts communicate with a Native 64 bits application which passes back results for displaying to its graphic interface

When I run in concurrency mode, an extra tab is displayed next to Collection (Error) - Just below, the window says [Cannot display data], the data cannot be displayed: there is no viewpoint applicable for data

The application waits for a pipe communication messageto arrive contains the data to display - It works for Hot Spots analysis or outside the tool - No other message is displayed that justifies the operation

Sal

[Salvatore_Li_Mandri]

Hello, again

FYI: Installed update 10 - no difference in operation from what I reported

[Salvatore_Li_Mandri]

Hello, one more time

FYI: installed update 11 - It now offers the possibility to lunch a debugger when the problem occurs.

This allowed to see the failure in a ReadFile() API, which produced by an access violation 0xC0000005 reading 0x0000001C, however I cannot execute the line containing the GetLastError() at the return to figure out what is wrong, or using the debug register for similar purpose

Do you have any sugestion?

The exception never occurs if the "Cpu Sampling interval time" is changed from its default value of 1 mSec to 1.2mSec or above - WHat is the significance of this?

Best Regards - Sal

[Bernard]

if ReadFile() caused AV exception can you post the arguments passed to this function?

[Salvatore_Li_Mandri]

As for your request

Thanks: Sal

[David_A_Intel1]

Hi Sal:

I apologize for not responding in such a long time.  Email update notifications were not getting through to me. :(

Regarding

The exception never occurs if the "Cpu Sampling interval time" is changed from its default value of 1 mSec to 1.2mSec or above

Are you referring to Concurrency analysis or Basic Hotspots, or both?

Concurrency uses instrumentation to insert code into all threading APIs.  Do you have some kind of watchdog timer that would cause your app to terminate if the messages from 64-bit app are not received in a certain about of time?  Instrumentation increases overhead and can slow your application's responsiveness.

[Salvatore_Li_Mandri]

Hello MrAnderson:

To answer your latest question, the exception happens when using Advanced HotSpot analysis where testing is done from inside the stand alone tool IDE - When the same test is run from VS2012 IDE, it appears to run fine even with 1mSec sampling. (??)

The exception resurfaces again when running the Concurrency analysis in either environment

Since I was able to identify the offending call (thanks to the feature that allows me to open a separate debugger session) and since I cannot go past this line to obtain the reasoning for the exception (I cannot call GetLastError() programmatically because of the exception that just happen) do you have any sugestion about confirming your intuition? I should be completing the operation inside 5 Seconds, but I have no evidences examining my code that this is happening. I guess I could try to double up this timing to second guess my-self.

Best regards, Sal

[David_A_Intel1]

Hi Sal:

If it works inside Visual Studio*, then I would suspect a configuration issue.  That is, your VS project is set up to allow everything to work, including any special settings related to your app communicating with the other 64-bit app, but the standalone VTune Amplifier XE project is not.  Since I don't know the intricacies of your application, you will need to examine all the project configuration and ensure that everything that is needed is set.  For example, are you setting any environment variables in the VS project but not in the VTune Amplifier XE project?  Any special setup so that the two apps can communicate?  Are you doing it for the standalone project?

However, again, since it fails in both environments with Concurrency, I would suspect that the instrumentation is "perturbing" your application enough to cause the problem.  What happens when you run Locks and Waits analysis?  You can view concurrency information from the Locks and Waits data, as well.

[Salvatore_Li_Mandri]

Hello,

I know what you are saying, but looks to me that if it was a configuration issue, the Basic Hotspots analysis would not work - but it does. Additionally the XE Inspector (Memory and Thread Checking) report no issue when running the same code. The XE tools both inherited the project settings from the VS2012 project (which I verified to be correct).

Lastly, the issue is basically present in all the type of testing that can be run but the Basic Hotspot. This mean also the Locks and Wait.

Intel Support is taking a look to the issue as well. I will report their findings ASAP once they reply something.

Thanks for all your help - Sal

[David_A_Intel1]

Ok, thanks.  Note, however, that Basic Hotspots does NOT use instrumentation, so that could explain the difference.

[Salvatore_Li_Mandri]

Hello,

The issue has finally been resollved at my end...

It turnout to be a stack overflow by one of the threads that executes in parallel. The default stack size value of (0) in _beginthreadex() is interpreted as 1Meg (so the documentation says) in 32 bits mode. When the code is recompiled in 64 bits mode, I assumed that the (0) value was automatically interpreted as 2 Meg. instead.

While I do not know the validity of my assumption I decided to manually to double up the default value the threads were creating.

At soon I started using the 2000000 (2 Meg) value in place of zero (same as Def. 1 Meg) your tool run happyly to the manual program termination.

It was kind of aggravating that the problem surfaced only if the application was run from the Amplifier XE and not while been run from the Inspector XE - This fact produced an unclear source of the problem.

Feature request: What would have help is to know at the end of a run (Inspector/Amplifier, whichever is more approprirate) how much stack each thread in the application consumed.

Unless I am mistaken, one of the very first Intel tool (ThreadChecker or ThreadInspector - Several years ago) were reporting this value at the end of the run. It would be nice to have that feature back.

Thanks:

Sal

[Salvatore_Li_Mandri]

Sorry,

I forgot to include an interesting link to read about the need to have more stack in 64 bits - I hope this helps anybody that develops 64 bits code

http://software.intel.com/en-us/blogs/2010/07/01/the-reasons-why-64-bit-programs-require-more-stack-memory