Unable to perform a Concurrency or Locks and Wait Analysis: "Failed to finalize result"

Unable to perform a Concurrency or Locks and Wait Analysis: "Failed to finalize result"

I'm trying to run a Concurrency or Locks & Wait Analysis on some of my applications. On one very minimal test application this works fine, but on several others built from the same codebase I see the following error:

"Analysis is completed successfuly.
Failed to finalize the result."

In the Collector messages window I have this:

" Warning: user32.dll instrumentation requested more than once ...
Target process's profiling finished but the following processes are still being profiled:
PPID PID STATE NAME
003260 006244 RESUME MidiTester.exe

You may stop collection manually. The processes listed above will be terminated."

One project will analyze ok in Win64 but not Win32.

I have the same symptoms as:

I'm building against Qt 4.7.2 (dynamic link). VS2008, C++ XE Studio 2011 update 2.

Any idea why it's ok for some projects but not others?

publicaciones de 16 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

It appears that
the application is still running for some reason although the target finished. Have you tried the -duration option as
suggested in the other forum post?
Alternatively, manually stop your application execution. With this, does the behavior change? In terms of the Failed to finalize the
result. You can try to re-resolve the results after the application has ended
to see if the results can then be finalized.

I've been unable to find this option in the UI. Is this supplied as an argument to my own application? I can't see anywhere in the UI to specify command line arguments to the analyzer, and the only duration related option is the 'Duration time estimate' combo box.

To set duration for
a project in the Intel VTune Amplifier XE GUI:

1.) Click the
Project Properties button
2.) In the Target
tab on the left pane select the method you wish to use (Launch Application,
Attach to Process, Profile System). The properties
are then displayed for that method
3.) To set a
duration, click the Automatically stop collection after (sec): checkbox option
4.) Enter some
number of seconds in the field to the right of this option
5.) Click the OK button
once you are done setting project properties

Thanks for the clarification. I've tried setting that and on one occasion it has produced a little more information. This showed that my application was exiting straight away because it uses some 'singleton application' code (specifically Qt's QtSingleApplication class) that checks for an existing running instance via sockets and lock files. It appears that for a 32-bit process the application may be being launched twice by VTune, which triggers this singleton code and therefore exits straight away. This doesn't seem to happen in a 64-bit build.

Does VTune cause the executable to be loaded and run more than once?

Are the Intel
VTune Amplifier XE Project Properties > Advanced > Allow multiple runs
or Analyze child processes options enabled?
If so, temporarily disable these options and attempt a new run to see if
/ how the behavior changes. Let us know
the outcome.

If the behavior
persists, can you let us know the VTune Amplifier command line you are running
where the unexpected behavior occurs? To
get the command line in the GUI, click the Get Command Line button in the
lower right corner of the GUI. Then copy
/ paste the command into your reply. If
there is detail you wish to be private, you can make the forum post private if
you wish.

It may be helpful
for us to examine one of your VTune Amplifier results file, however, we can
hold off on this until we know more about the command line being ran and the
results of any changes in behavior based on the info in the previous paragraph.

Thanks
Rob

Hi Rob,

Disabling those two options has no effect -- I'm getting the same behaviour every time now.

The command line parameters are:
amplxe-cl -collect concurrency -knob accurate-cpu-time-detection=false -knob collect-signals=false -no-follow-child -mrte-mode=auto -target-duration-type=short -no-allow-multiple-runs -no-analyze-system -data-limit=100 -slow-frames-threshold=40 -fast-frames-threshold=100 --search-dir sym=c:/Source/trunk/Source/Build/MidiTester/Release.Win32 --search-dir sym=C:/Source/trunk/Source/Projects/Utilities/MidiTester --search-dir sym=c:/windows/symbols --search-dir sym=c:/windows/symbols/singlepdbs --search-dir sym=c:/windows/symbols/microsoftpublicsymbols --search-dir sym=c:/Source/trunk/Source/Build/DeviceTester/Release.Win32 --search-dir sym=c:/Source/trunk/Source/Build/FourCCConverter/Release.Win32 --duration 60 -- c:\Source\trunk\Source\Build\MidiTester\Release.Win32\MidiTester.exe

I will be happy to supply further details if required.
thanks
Paul

Paul,

Thank you for the additional
information. I will ask Development
about possible interaction with QtSingleApplication or similar situations and
hope to have an update for you soon.

I am not sure if you have
tried this already, but if you have the application running and attach Intel
VTune Amplifier XE to your Application process (By name or PID) do you get
different behavior? This is assuming
that your application runs for enough time to gather data using this method.

To attach to process:

1.) Start your application
2.)Then switch over to
Amplifier
3.) Click on Project Properties
> Attach to Process
4.) Select the Process name
or PID radio button and enter either the process name or PID
5.) Click Start
6.) Click Stop to stop
sampling or wait until the application runs its course

Additional information about
attach to process can be found here.

Another option may be to
start the analysis paused (Start Paused button) and click Resume after your
application has gone through its warm up.
Information about start paused relating to the GUI can be found here. There is also a video here.

Also an option might be to use
the Collection Control API within your source.
Additional information about this can be found here. Let me know if this is an option and you need
additional information about Collection Control.

Thanks
Rob

Thanks for the suggestions. I've tried attaching to the process, but this has the effect of crashing it (my application).

This problem seems to be unique to Win32 applications -- I've not had any problems at all with my x64 binaries. I've tried several Win32 applications built from our codebase and VTune fails in the same way on all but the most trivial, so I'm inclined to think there's something about our codebase or the libraries we use which trips VTune up.

Can you let me know the
following?

- The version and build if
possible of amplxe-cl you are running.
To do this, run amplxe-cl version at the command prompt. If you are running version 2011 with less
than update 3, can you update to a minimum of update 3 or the latest which is update
4 of amplxe-cl?

- Does the analysis behavior always
come back with a reference to user32.dll?

- Can you let me know the
processor manufacture and model and also OS version you are working with?

- Are you running the
analysis as Administrator?

Hi Rob,

  • I'm running Update 3 (build 150226), I'll try to get hold of Update 4.
  • Yes, it does appear that user32.dll is always referenced in the collector log. It never seems to get further than that.
  • Intel Core i7 950 @ 3.07GHz. Win 7 64-bit
  • I've tried running with elevated privileges (ie run as admin) and normally (my user has admin privileges but UAC is on)

thanks
Paul

Paul,

Thank you for the additional information. So far I have not been
able to replicate the behavior or locate an exact previous report with an apparent
applicable resolution. However, there
may be some leads To narrow the scope of the issue further can you let me know
the following?

- When the behavior occurs, does Windows (Windows 7 / 64-bnit in
your case) report any Error level System events in the Event Viewer >
Windows Logs > System?

- What compiler and version are you working with?

I suspect that update 4 will produce the same behavior, but it is
worth a try. If by chance you have a
small reproducer MS Visual Studio solution that would be ideal.

Thanks
Rob

Hi Rob,

Sorry for the delay in responding. I've checked the Event Viewer and sure enough there is a report of my application crashing when VTune tries to profile it. I've dug out the crash log file and analysed in windbg and it shows the following stack:

PRIMARY_PROBLEM_CLASS: INVALID_POINTER_WRITE

qjpeg4+0x2049c
tpsstool!main+0xa8110
QtCore4!QEventDispatcherWin32::processEvents+0x308
tpsstool!CharmVersionC+0xe3f64
tpsstool!CharmVersionC+0xd82f1
QtGui4!QWindowsVistaStyle::pixelMetric+0xa0
QtGui4!QCommonStyle::subElementRect+0x1d91
QtGui4!QWindowsStyle::eventFilter+0x1dd
ntdll!RtlpLowFragHeapAllocFromContext+0xaec
kernel32!HeapFree+0x14
msvcr90!free+0xcd [f:\dd\vctools\crt_bld\self_x86\crt\src\free.c @ 110]
MidiTester!GuiWindowHandle::~GuiWindowHandle+0x1a [c:\source\trunk\source\shared\gui\guiwindowing\guiwindowingqt\guiwindowhandle.cpp @ 50]

I suspect that some of the elements in the stack trace are bogus, but it does appear to point to a conflict between the tpsstool's injection into the process and the qjpeg4.dll (which is part of Qt). My build environment is VS2008 SP1. Unfortunately I can't provide a very minimal solution as this only occurs when I link against libraries in our codebase (which link against Qt), though I can provide some binaries if that's any use.

To reiterate, 64-bit builds work fine, this just seems to affect 32-bit builds.

Paul,

Development is asking for
additional information to help debug and / or replicate the behavior. First, would it be possible to install the
latest update for Intel VTune Amplifier XE which you can obtain from the
Intel Registration Center at https://registrationcenter.intel.com
after you login? Then try to replicate
the behavior. Let us know if the error
message or behavior changes.

If the issue persists, Development
is asking if you can please attach a debugger after the crash and collect
stacks of threads in the failed application?
If this is not possible then can we obtain either a reproducer to
investigate locally or remote access to the machine where it crashes?

Sincerely,
Rob

Hi Rob,

I will try installing the latest version when time permits. Thanks for your response.

Paul

Hi Rob,

I have now updated to the latest version (2011 SP1) and -- as far as I can tell up to now -- it seems to have fixed this problem.

Thanks for your help
Paul

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya