Call Stacks

I find it interesting how deep we tend to go as developers when we’re building on top of other code. I’ve been debugging a memory leak in our app and this is part of a call stack for a potential culprit.

	ntdll!RtlLogStackBackTrace+7
	ntdll!RtlpAllocateHeap+C4
	ntdll!RtlAllocateHeap+23A
	msxml6!LEVEL2::operator new+16 (d:\w7rtm\sql\xml\msxml6\core\base\pointer.cxx, 68)
	msxml6!AddPointerToCache+70 (d:\w7rtm\sql\xml\msxml6\core\base\pointer.cxx, 204)
	msxml6!SlotAllocator::NewPage+40 (d:\w7rtm\sql\xml\msxml6\core\base\slot.cxx, 546)
	msxml6!SlotAllocator::Alloc+98 (d:\w7rtm\sql\xml\msxml6\core\base\slot.cxx, 339)
	msxml6!Node::operator new+26 (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 257)
	msxml6!Node::newNode+F (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 295)
	msxml6!Node::_clone+1C (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 2971)
	msxml6!Node::clone+13 (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 3028)
	msxml6!Node::cloneChildren+66 (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 3080)
	msxml6!Node::clone+63 (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 3050)
	msxml6!Node::cloneChildren+66 (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 3080)
	msxml6!Node::clone+63 (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 3050)
	msxml6!Node::cloneChildren+66 (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 3080)
	msxml6!Node::clone+63 (d:\w7rtm\sql\xml\msxml6\xml\om\node.cxx, 3050)
	msxml6!Node::clone+34 (d:\w7rtm\sql\xml\msxml6\xml\om\node.hxx, 486)
	msxml6!DOMNode::cloneNode+9A (d:\w7rtm\sql\xml\msxml6\xml\om\domnode.cxx, 1642)
	msxml6!W3CDOMWrapper::cloneNode+17 (d:\w7rtm\sql\xml\msxml6\xml\om\w3cdom.cxx, 254)

It’s kind of fascinating, isn’t it? Notice all the steps we go through to allocate memory. All the way from Node::operator new up to the actual call into the NT runtime, RtlAllocateHeap.