Severe (157): Program Exception - access violation

[jirina]

When I try to run any of the 3 analyses available in Advisor I get the error "Severe (157): Program Exception - access violation" and the line with the call of "omp_get_num_procs" is listed in the console output:

use omp_lib
integer*4 procs
procs = omp_get_num_procs ( )

I double checked that I use following settings in my project: /debug:full, /Od, /check:none, /libs:dll /threads /dbglibs (Debug Multithread DLLs), /Qopenmp.

The complete compiler settings are: /nologo /debug:full /MP /Od /fixed /extend_source:132 /Qopenmp /fpscomp:general /Qdiag-disable:8290,8291 /debug-parameters:all /warn:declarations /warn:truncated_source /warn:noalignments /warn:interfaces /assume:byterecl /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc100.pdb" /traceback /check:none /libs:dll /threads /dbglibs /c

The (almost) complete linker settings are: /INCREMENTAL:NO /NOLOGO /MANIFEST /DEBUG /SUBSYSTEM:CONSOLE /STACK:100000000

Running the (console) application in the debug mode and in the release mode works well and the "omp_get_num_procs" function return the expected and correct number of processors.

I am using Parallel Studio XE 2015 Composer Edition, Advisor XE 2015 Update 1 and Visual Studio 2010 Professional SP1 on Windows 7 Professional 64-bit.

Is there anything I could try to make Advisor work as this was no problem with 2013 versions of Intel software?

[Bernard]

>>>procs = omp_get_num_procs ( )>>>

By reading your description it seems that omp_get_num_procs() directly or indirectly caused the access violation.

Can you put breakpoint on that function call and perform step-in?

[jirina]

As I described in my original post, debugging works well and I get no access violation errors. Stepping into omp_get_num_procs does not work - the behavior is the same like if I just step over. 

Anyway, even if I were able to step in, I would not be able to find out, why everything works well in the debug mode, but running Advisor causes an access violation error. Could it be that I use wrong compiler and/or linker settings?

Finally, I could see in the console that libiomp5md.dll and libttnotify.dll are listed after the error occurs. Does this help to find out what is wrong?

[jirina]

Could anyone from the Intel support comment on the issue I am having, please? It is a showstopper for me, preventing me from using Advisor. :-(

[Robert_L_Intel1]

Hello, Jirina - Please use the feed-back tool to collect more diagnostic data, using the following console command to generate the report:

advixe-feedback -create-bug-report=Jirina_report.zip

Requirements:
- Please run the advixe-vars.bat file and ensure you have write access to the output or working directory.

When the process has completed, please upload to me as time permits.

If you prefer, for secure communications with the VTune Amplifier XE support staff, you can always submit your problem to Intel(R) Premier Support.

https://premier.intel.com/
 
It's free, secure technical support.

[Robert_L_Intel1]

Hi Jirina - Additionally, Windows 7* should have something called Application Verifier already installed.  You could try enabling these additional debugging flags on the system to flush out the problem.  When the access violation occurs, then attach the debugger and get a crash dump.  The easiest way to do that is with process explorer from sysinternals.

https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Steps:

- Start -> Run -> appverif.exe

Under the file menu, add the Advisor application to the list.

Leave the "basics" check-box checked.

Save the settings.

Launch Intel® Advisor XE.  These settings may cause the application to crash more consistently and perhaps at an earlier time in the execution path.  If you get a Windows* error dialog, you can use process explorer to collect a crash dump and upload that to me.  If not, the information required will be contained in the feedback report and you can ignore these steps.  I will engage our engineering team with the results.

[jirina]

Hello Bob. I have to apologize here - when I started this thread, I reported a problem with Advisor, but what I meant was Inspector; I don't know how I could make such a stupid mistake and keep asking for support here. I later reported the problem correctly here https://software.intel.com/en-us/forums/topic/541592.

In any case, I think I can use steps from your description even for Inspector; I used inspxe-feedback to create a report that I've just uploaded to Intel Premier Support.

I am going to continue with the App Verifier stuff.

I apologize once more for reporting Advisor instead of Inspector; I hope I did not cause any inconvenience or problem.

[Robert_L_Intel1]

Hi Jirina - Thanks for clarifying.  I might have guessed it if I'd paid a little more attention :)  You are correct in that my post applies to all the Intel® developer tools, depending on the scenario.

Some of the scenarios require process attachment and code injection that is very similar to how a debugger works, which can make crash dump collection from another, third-party tool more difficult or impossible.  This is one of the reasons why we do the feedback reports.

[jirina]

Hello Bob, thank you for your understanding.

I started following steps described in your other post, but it seems to be over my capabilities; I am not such an advanced expert to be able to do the second part of the post.

I installed the Application Verifier (4.0, x64) and made sure the Inspector application is in the list. I was not sure what executable I should add, so based on the Process Explorer, I added "inspxe-runtc.exe" that is run by Visual Studio when I start an analysis. Is this the correct executable?

I don't know how exactly I should continue. When I run an Inspector analysis and the access violation occurs, Windows offers me to Debug or Close the program. Is this the moment I should open Process Explorer and attach the debugger? Attach to what process? My application? The context menu in Process Explorer offers to debug a process or to create dump and I don't know what exactly I should do and how to combine it with the dialog Debug / Close program. So, a detailed step by step list of instructions would be helpful here; I am sorry not to be sufficiently advanced...

[Robert_L_Intel1]

Hi Jirina - Good questions, all.  Actually, now that it's Inspector and not Advisor, many things change.

If your central question is how do I debug my application when it only crashes when run in Inspector, then, Application Verifier is your friend.

Add your application to Application Verifier and see if you can get it to crash.  If you can, then run it in a debugger and you can debug it.

If it still only crashes in Inspector, then it would be helpful to upload the crash dump to us.

In the latter case, when the dialog shows, leave it open and see if Process Explorer will allow you to capture a full dump.  This feature is on the context menu of the processes view list items. 

**Addendum - In either case, though, you want to be dumping the faulting process.  So, if it's your application, then get a dump for that.  If Inspector, get a dump for that one, whichever it is.  The Windows* dialog should be telling you which process crashed.  We can start with that and if the engineering team needs more, I will tell you.

[Bernard]

You can also enabling windbg as a default post-mortem debugger and enable the option to break on any exception. When the AV occurres hopefully windbg will break-in and display the offending thread callstack.

[jirina]

After a long time spent on a business trip, I finally have time to get back to the topic.

I tried following:

• I ran both 32-bit and 64-bit version of my application from Visual Studio using both Ctrl+F5 and F5 only, with compiler and linker settings recommended for Inspector, and with Application verifier opened and my application added to it. Everything is running well and my application is running normally.
• Having my application added to Application verifier and starting Inspector, my application did not start at all and there was no log corresponding to it in App verifier. So, for now, I gave up using App verifier together with Inspector.
• If I use Inspector and App verifier is not running, my application crashes as I originally reported, but only the 64-bit version. Good news is that the 32-bit version seems to work without any problems.

The main conclusion from tests described above is that my application crashes only in 64-bit version and if it is started by Inspector. I used Process Explorer to create a full dump for my application - it is 172 MB in size and it might contain information that is confidential, so the question is how I can send it to you.

[Kirill_R_Intel]

Hello. The best way to send us the dump is to open an issue in premier.intel.com. It allows attaching such files and provides secure access to your information.