line numbers in call stacks?

[Eric.Hill@sas.com]

Hey,

I'm noticing on the call stacks for allocations, I get the function name, and going to source code takes me to the top of that function, but I don't get line numbers. So all I know is that somewhere in that function, this memory was allocated. This is probably okay for managed memory, since I have pretty good type information, but for native memory, where I really don't have type information, this is sort of limiting. Is it possible for the call stacks to include line numbers so I can get to the exact line of an allocation?

Thanks,

Eric

[Andreas Suurkuusk]

Line number information is not available in managed call stacks (for performance reasons), but should be available in native call stacks (see screenshot below).

Native line numbers

LineNumber.png (25.07 KiB) Viewed 13160 times

Are you missing line number information for native code, even though full symbol information exists?

In order for native call stacks line numbers to be available, the native symbols must be initialized correctly and the symbol file must contain source information. To get native call stack information for OS and .NET runtime code, make sure that you retrieve symbol files from the Microsoft symbol store (see screenshot).

Symbols file location

Symbols.png (39.64 KiB) Viewed 13160 times

[Eric.Hill@sas.com]

Maybe this is the issue: I am missing line number information for the allocation of native memory, but that allocation of native memory is taking place in C++/CLI code (so managed code). I added an obvious native memory leak to my code to see if I could find it with MemProfiler. The memory that I am allocating is native (it shows up in MemProfiler under "C++ Runtime::Memory"), but the code in which I am allocating it is C++/CLI code, so it is managed code. So does that mean I am out of luck for line numbers in that case? I will have to try doing something similar from native code.

The vast majority of our native memory allocations should be happening in purely native code, so I doubt this is a major issue for me, now that I think about it.

Thanks,

Eric

[Eric.Hill@sas.com]

Sadly, it's not good. I changed my code so that I am leaking native memory from native code. However, at the point that the native code allocates the leaked native memory, the call stack is still mostly managed code. The native code that allocates the memory gets called downstream from a WPF click handler. Since the user interface of my application is WPF, pretty much every call stack is going to start from managed code. So no line numbers for me, even for native code allocating native memory. Does that sound about right?

Any way to tell MemProfiler to *only* grab native call stacks? Or to only grab native call stacks if the application is allocating native memory from native code? Otherwise, it seems MemProfiler is going to be of limited help finding native memory leaks in my app.

Thanks,

Eric

[Andreas Suurkuusk]

You will not get any line number information for managed frames in a call stack. But, in a mixed native and managed call stack, you should get line number information for all native frames that have source debug information. So in your example the call stack should look something like:

Code: Select all

Kernel32!HeapAlloc(...)                    --- Native system function without line number
NativeLibrary!NativeFunction(...) Line 123 --- Native function with line number
[Managed to native transition]
ManagedAssembly!WPFControl_Click(...)      --- Managed frame without line number
...

Are you not seeing the line numbers for the native function frames? If you are not, then there's something wrong that we will need to investigate further.

[Eric.Hill@sas.com]

If I set a breakpoint where the native code allocates the leaked native memory, the call stack that Visual Studio shows me looks like this:

Code: Select all

jmp.exe!launchPlatform(EPlatform platform=EDistrib, const JString & platformName={...}, DataTable * dt=0x0d882d78, PlatformParms * parms=0x0d8b0ba0, DisplayBox * displayParent=0x0d8b0f38, Top * t=0x00000000, EvalContext * c=0x0038b1b8, Scriptable * * toObj=0x0028e044, OwnerOf<Top> * resultObjRef=0x0028e058, bool rerunning=false)  Line 1987	C++
jmp.exe!PlatformDlg::actionGo(OwnerOf<Top> * tPlatform=0x00000000)  Line 1625 + 0x32 bytes	C++
jmp.exe!PlatformDlg::actionButton(int which=1)  Line 723 + 0x15 bytes	C++
jmp.exe!ButtonDisplay::clickAction(GContextMeasure & __formal={...}, GContextMeasure & __formal={...}, GContextMeasure & __formal={...})  Line 854	C++
[Managed to Native Transition]	
jmp.exe!WinHost::HostButtonDisplay::onClick(System::Object^ sender = 0x057d706c, System::Windows::RoutedEventArgs^ args = 0x0590601c) Line 279 + 0x37 bytes	C++
jmp.exe!WinHost::HostButtonDisplay::delegate_proxy_type::onClick(System::Object^ arg0 = 0x057d706c, System::Windows::RoutedEventArgs^ arg1 = 0x0590601c) Line 39 + 0x4c bytes	C++
PresentationCore.dll!System.Windows.RoutedEventHandlerInfo.InvokeHandler(object target, System.Windows.RoutedEventArgs routedEventArgs) + 0x78 bytes	
PresentationCore.dll!System.Windows.EventRoute.InvokeHandlersImpl(object source = {System.Windows.Controls.Button}, System.Windows.RoutedEventArgs args = {System.Windows.RoutedEventArgs}, bool reRaised = false) + 0x1bf bytes	
PresentationCore.dll!System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject sender = {System.Windows.Controls.Button}, System.Windows.RoutedEventArgs args = {System.Windows.RoutedEventArgs}) + 0x79 bytes	
PresentationCore.dll!System.Windows.UIElement.RaiseEvent(System.Windows.RoutedEventArgs e) + 0x17 bytes	
PresentationFramework.dll!System.Windows.Controls.Primitives.ButtonBase.OnClick() Line 68	C#

Code: Select all

MSVCR90!malloc( size_t )
[Unidentified frame(s)]
[Managed to native transition]
jmp!<Module>.WinHost.HostButtonDisplay.onClick( HostButtonDisplay*,object,RoutedEventArgs ) hostwinbuttondisplay.cpp
jmp!WinHost.HostButtonDisplay.delegate_proxy_type.onClick( object,RoutedEventArgs ) hostwinbuttondisplay.h
PresentationCore!System.Windows.RoutedEventHandlerInfo.InvokeHandler( object,RoutedEventArgs )
PresentationCore!System.Windows.RouteItem.InvokeHandler( RoutedEventArgs )
PresentationCore!System.Windows.EventRoute.InvokeHandlersImpl( object,RoutedEventArgs,bool )
[Skipped frame(s)]
PresentationCore!System.Windows.UIElement.RaiseEventImpl( DependencyObject,RoutedEventArgs )
PresentationCore!System.Windows.UIElement.RaiseEvent( RoutedEventArgs )
PresentationFramework!System.Windows.Controls.Primitives.ButtonBase.OnClick()
[Truncated]

You can see the [Managed to Native Transition] in both call stacks, but whereas Visual Studio shows me functions with line numbers in the frames above that, MemProfiler just shows [Unidentified frame(s)]. So I guess the thing to investigate is why I'm just seeing [Unidentified frame(s)] instead of the native stack frame info.

Eric

[Andreas Suurkuusk]

The "[Unidentified frame(s)]" indicates that the profiler has failed to load the debug symbols. What version of the profiler are you using? We recently fixed a bug related to symbol files loading. If you are not using the latest version of the profiler (v3.5.136), I recommend that you download it from http://memprofiler.com/download.aspx.

If you still don't get line number information, could you send us log files from the profiler? You can create the log files by providing the /log:<path> argument to the profiler executable. E.g. by running the following command:

"C:\Program files\SciTech\NetMemProfiler3\NetMemProfiler.exe" /log:c:\MemProfilerLogs

This will create a set of log files in the "C:\MemProfilerLogs" folder. Can you send them to support@scitech.se?

[Eric.Hill@sas.com]

Andreas,

I realized about a week after sending the log files (or so I thought) that they had never left my outbox because our corporate Outlook limits e-mails to 10MB, and even compressed the log files were 60MB+. Do you have another way for me to get them to you?

Thanks,

Eric