Inspector hangs

[BatterseaSteve]

Hi

We are evaluating Inspector for purchase and have run it succesfully on one of our programs.

However, we have run into a hang when trying to inspect our main application. Even after leaving it running overnight.

I am looking for pointers as to how to overcome this.

The OS is Windows 7 64bit

The application is 64bit multithreaded OpenGL with Trolltech Qt interface running on intel+nVidia

It is quite large - but we are trying to profile the complete app as a whole (we have already unit tested most of the modules)

I have added the zipped output logs

Cheers

Steve

[Mark_D_Intel]

Steve,
It appears you have selected 'Analyze stack accesses' when setting up the analysis type. This option can greatly increase the run time (due to increased overhead). Try running it again without this option set.
Also, you could try running at the lowest level of analysis ('Detect Leaks') and see if it successfully completes there or not.

Mark

[Bernard]

I'm too late with my answer probably the thread creator won't read this, but I'd like to add my 0.02 cents. When some process hangs I would often recommend use AD plus tool to dump hung process address space.Another option is to run your faulty process under debugger and issue the cpu-hog metacommand !runaway to collect the time spent by variuos threads.

[BatterseaSteve]

Hi,

Well, we went ahead and purchased VTune - mainly for the profiling tool. But we still are unable to load our main program through Inspector.

I've tried turning off pretty much everything except access violations (which is what we are looking for). The program does not hang when run in isolation. And the threads are already optimised. It seems to hang trying to upload a texture to the GPU. So my first question is whether there is anything I should be aware of when trying to analyse threaded OpenGL/Cuda programs? Or should this 'just work'?

Is there anything I can do to determine where the system is hanging?

Cheers

Steve

[Bernard]

>>>It seems to hang trying to upload a texture to the GPU>>>

If I understood it correctly your program hangs while try to upload texture to the GPU or Inspector hangs?

[BatterseaSteve]

Apologies for delay - I've been involved in other issues up to now.

To answer your question.

Our program hangs.......

As in "The program does not hang when run in isolation.....It seems to hang trying to upload a texture to the GPU"

My experience of using memory debuggers and profilers with OpenGL multi-threaded applications has not been great - in fact I've never found one yet that works.

That is why I asked the questions:

"Is anything I should be aware of when trying to analyse threaded OpenGL/Cuda programs? Or should this 'just work'?"

"Is there anything I can do to determine where the system is hanging?"

Steve

[Peter_W_Intel]

Latest Inspector XE 2015 only support native code(C/C++, Fortran), one exception is C# on Windows*. Please see releasenotes.

[Bernard]

>>>To answer your question.

Our program hangs.......

As in "The program does not hang when run in isolation.....It seems to hang trying to upload a texture to the GPU">>>

What about trying to use Xperf in order to find which function hogs the CPU?

[Robert_L_Intel1]

I've noticed that sometimes the graphics driver version can be important in a case like this.  Is there an update there perhaps that you could apply?  I didn't see that you specified whether or not this is high or low cpu?  I think in a possible scenario such as Mark is suggesting, you would likely see high cpu, or at least some activity.  Whereas, if it's a driver issue, maybe no cpu (i.e. deadlock)?

Do we know which it is, high or low cpu? 

Since you have reduced to just AV and still get a repro, I'm guessing low-cpu hang ... possible graphics card driver issue?

Otherwise, to answer one of the previous questions, there is a tool from sysinternals that you can use to get a quick call stack sometimes.  In Process Explorer, do a right-click -> properties -> threads (tab). From there, find a thread of interest and use the buttons on the bottom to suspend/resume and view the call stack.

There is a 'configure symbols' item under the 'options' menu as well, which will make use of the Microsoft* symbol server, if need be, or your own local symbol store/cache.

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

http://blogs.msdn.com/b/vijaysk/archive/2009/04/02/getting-better-stack-traces-in-process-monitor-pr...

Could you post a call stack using the above tool?  You may be able to suspend the thread and still get a stack, if it's a high-cpu, too.