Clever Geek Handbook

Write call stack and values ​​at breakpoint?

Background

I'm trying to track down a memory leak problem where I know (from _CRT_DEBUG_MALLOC and MFC and CRT leak detection) the specific line where the memory leak is occurring, but since this line is being called so often I don't know which call is actually leaking. And the allocation number + __p__crtBreakAlloc()

does not help, as every different allocation number starts every time.

Anyway, for the background. If you think I should use a different tool, please leave a comment. I would appreciate it if the answers would focus on the actual question instead of my main problem, as I find much more interesting than the leak itself (I will find that it ends up through enough popping).

Question

Is it possible that there is a breakpoint in WinDbg (I'm sure it's not in VS) with the following properties:

  • It won't break. (So ​​this is the "point of the trail")
  • On impact, it records the call stack (up to a certain depth)
  • It should also be recording some kind of global state (variables, maybe just the raw value of a memory address)

Is it possible? How?

+3


source to share


3 answers


To answer each of your questions:

  • no breaking breakpoint:

    bp myDll!<namespace>::myClass::myFunc "gc"

    - you can execute commands separated by double quotes, in this case when the breakpoint is hit, just keep going

  • on hitting a breakpoint, unload the call stack to a certain depth

    .kframes 0n50; bp myDll!<namespace>::myClass::myFunc "kb;gc"

    - this sets the call stack length to 50 (default 20), 0n

    tells us we are decimal based. the command in double quotes after bp

    will remove the call stack and then continue

  • write some global state

    dt myVar

    - global variables will be displayed, in addition, will be used d* myVar

    dd myGlobalVar

    make sure pdbs has no personal characters - you should check the info for dt

    as there are certain switches to handle unicode strings, depth, etc., besides, you can easily observe the values ​​in the clock window in WinDbg and also see the document aboutd*

Also, WinDbg has an automatic leak detection command:



!heap -l

but i found it a little hit and miss sometimes, more info here

+1


source


What you are trying is a very crude approach that has very little positive effect when dealing with memory leaks - at least something like a UMDH is needed to deal with the complexity of tracking a stack trace based leak. Even if you do manage to do multiple traces, it will probably be too verbose for you to handle manually.

There is a general debugger extension to track all kinds of leaks that will give you a little leverage if you go to the manual route: the domdbg extension



Here is a python script helper I wrote that you may find helpful if you go the UMDH path - it helps you automate the snapshot taking a bit and might be more efficient when parsing traces as it will cache character information and store traces in binary (as opposed to the textual representation used by UMDH): pyumdh

+1


source


There is also a tracer extension that can track arbitrary open and close operations.

+1


source






More articles:


All Articles