PTU - Problem with symbols on Windows

PTU - Problem with symbols on Windows

I have noticed that both PTU and VTune loose track of symbols in certain .dll's for code build with the .NET2005 MicrosoftVisual C++ compiler when profiled with call graph. This appears to be related to the base address of the dll where routines reside.

By way of example I have the routine a in dll A.dll calling routine b in dll B.dll, calling routine c in dll C.dll. If I start from c in the profile output, it will say the parent is unknown. Through VTune support we have discovered that this occurs if the dll is in a relatively low address range, VTune, at least, drops the dll thinking it is a Windows system dll. I am testing on a 64-bit system, and in that case this appears to have happen for dll's located before the 2GB mark in memory.

We can work around the problem by relinking the .dll with the /base option and specifying a location, but this is not a great solution.

Does it make sense that what is happening in VTune would also be happening in PTU? If so, is there possibly a fix for this?



5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Matt,

A couple of questions that might clarify the situation:

  • Doesthe problemhappen on 64-bit Windows only? Can you try 32-bit?
    • You use 64-bit version of PTU, right?
  • By "it will say the parent is unknown" do you mean that it shows something like "unknown(s)" as function name? Or it just doesn't expand the parent at all?
  • Are all routines in B.dll non-resolved? If you get a sample in B.dll directly, do you get correct function names?
  • You say that you had similar problem with VTune Callgraph. What were the exact symptoms there?



Answers to your questions.

(1) The problem occurs on both 32-bit and 64-bit Windows. I am using the 64-bit version of PTU on 64-bit Windows and 32-bit on 32-bit Windows.

(2) It shows unknown(s) as the parent function name. It also has times that do not make sense. In this case I have a focus function called RECT_TRIUPDATE. Totalsamplesfor RECT_TRIUPDATE is 214 and self samples is 214. The parent listed in the Caller/Callee window is witha Total sample count of 1 and a self sample count of 169. I know that RECT_TRIUPDATE is called only by one routine in the code.

(3) Some of the routines in B.dll do get resolved. The code has both Fortran and C++. The only pattern I'm noticing so far is that it looks like in the dll's causing trouble, the Fortran symbols are resolved, but the C++ symbols are not. I did not do an exhuastive check, but in the example above the routine RECT_TRIUPDATE (Fortran) should show up as being called by the routine FactorizationDriver (C++). Both of these routines are built into a dll called ABQDDB_SOL_Core.dll.

If I sample directly I seem to largely have correct symbol names. I see one unknown(s). The function I'm looking for in the callgraph test, FactorizationDriver, does not show up in the sampling. This may not be too surprising because FactorizationDriver itself does not do too much work. It does not show up in a sampling run in the "corrected" build (see below) either, but does show up in the call graph run with the "corrected" build.

(4) Symptoms with VTune are as follows. (a) In the "Configure Call Graph" windows the suspect modules show up with "instrumentation status" listed as "Not instrumented" and the "Module Type" listed as "System." When looking at the results the behavior is similar. The routine FactorizationDriver fails to show up in the profile. What else might you be looking for in this description?

To give a bit more detail, if I look at the location of the executable being run here (standard.exe) in windbg it is located at 0x40000000 (2 GB) on the 64-bit Windows machine. Without any modification the dll ABQDDB_SOL_Core.dll ends up located at 0x6850000. If I run PTU with this address, I end up with the described behavior. If I then rebuild ABQDDB_SOL_Core.dll to 0x50000000 (using /BASE:0x50000000 on the link) then all is well (I checked with windbg that the dll does get relocated as a result of the relink).

This "corrected" build also behaves as expected in VTune.

I am not sure that the VTune and PTU issues are exactly the same. I just assumed since the same workaround seems to make both of them behave that the issue is related.

Finally here is the comment from VTune support that started us down the path of rebasing dll's. Also as far as we know using Visual Studio 200

"This sounds like an issue with the image base. Call graph assumes that DLLs based above a certain address are system libraries. One solution is to rebase the DLLs below some address. I don't remember the details, off the top of my head and can't find a reference. I will get you an answer tomorrow, but you might try just lowering the image base address."



Thanks a lot for the answers. They should be enough for us to dig into the issue. We will investigate it and let you know the results as soon as we can.

Thanks for using the tool and for the feedback. Stay tuned.

Great. Appreciate your response on this. Let me know if you need me to provide any more information.



Leave a Comment

Please sign in to add a comment. Not a member? Join today