line numbers in call stacks?

Use this forum for questions on how to use .NET Memory Profiler and how to analyse memory usage.

Moderator: SciTech Software

line numbers in call stacks?

Postby Eric.Hill@sas.com » Wed Mar 17, 2010 7:54 pm

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
Eric.Hill@sas.com
 

Re: line numbers in call stacks?

Postby Andreas Suurkuusk » Wed Mar 17, 2010 9:43 pm

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

LineNumber.png
Native line numbers
LineNumber.png (25.07 KiB) Viewed 6263 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.png
Symbols file location
Symbols.png (39.64 KiB) Viewed 6263 times
Best regards,

Andreas Suurkuusk
SciTech Software AB
Andreas Suurkuusk
 
Posts: 980
Joined: Wed Mar 02, 2005 7:53 pm
Location: Sweden

Re: line numbers in call stacks?

Postby Eric.Hill@sas.com » Thu Mar 18, 2010 11:22 am

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
 

Re: line numbers in call stacks?

Postby Eric.Hill@sas.com » Mon Mar 22, 2010 2:08 pm

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
Eric.Hill@sas.com
 

Re: line numbers in call stacks?

Postby Andreas Suurkuusk » Mon Mar 22, 2010 2:32 pm

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.
Best regards,

Andreas Suurkuusk
SciTech Software AB
Andreas Suurkuusk
 
Posts: 980
Joined: Wed Mar 02, 2005 7:53 pm
Location: Sweden

Re: line numbers in call stacks?

Postby Eric.Hill@sas.com » Mon Mar 22, 2010 3:16 pm

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
Eric.Hill@sas.com
 

Re: line numbers in call stacks?

Postby Andreas Suurkuusk » Mon Mar 22, 2010 3:40 pm

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?
Best regards,

Andreas Suurkuusk
SciTech Software AB
Andreas Suurkuusk
 
Posts: 980
Joined: Wed Mar 02, 2005 7:53 pm
Location: Sweden

Re: line numbers in call stacks?

Postby Eric.Hill@sas.com » Thu Apr 15, 2010 11:40 am

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
Eric.Hill@sas.com
 


Return to Using .NET Memory Profiler

Who is online

Users browsing this forum: Bing [Bot] and 4 guests

SciTech Software logo

© Copyright 2001-2016. SciTech Software AB
All rights reserved.


SciTech Software AB
Kartvägen 21
SE-175 46 Järfälla
Sweden


E-mail: mail@scitech.se

Telephone: +46-706868081

cron