How to know which function called this...

Started by
16 comments, last by Prozak 20 years, 2 months ago
Im trying to trace back, and do some debugging. I want to know who allocates a certain resource in my engine, cause it isnt geting deallocated... So, i could just copy a portion of the stack somewhere, and dump it right? No problems there I guess, but how do I know that 0x45FFAD2B is the address of my SQRT function (just examples) Is there some form of MACRO or shortcut in can use under Visual Studio to know and link an address to a function or class method? Thanks for any tips on this... Jester Says: Visit Positronic Dreams![Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"I say we take off and nuke the entire site from orbit. It''s the only way to be sure."
Advertisement
Currently using this simple code to copy the stack to a temporary buffer, so that i can analise it later...
void * buf[100]; // Any 4 byte type will do//ooooooooooooooooooooooooooooooooovoid jump_b(void){	void*		_esp;	__asm	{		mov _esp, esp	};	memcpy(buf, _esp, 100); 


Jester Says: Visit Positronic Dreams![Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"I say we take off and nuke the entire site from orbit. It's the only way to be sure."

[edited by - pentium3id on February 7, 2004 11:55:57 AM]
If you''re using MSVC, then enter the debugger, put a breakpoint in the function you want to know the parent of, and run to that breakpoint. In the lower left-hand corner, there should be a box that lists some variables and stuff, and it should have a few tabs at the bottom that say "Auto", "Locals", and "this". At the top of that box is a combo box that says "Context", and the current function prototype should be listed. Clicking the combo box will give you a complete list of the current function stack with full prototypes, and by selecting one, it will take you to the exact point in your source (or disassembly if it''s a system function) where your function was called.
Thanks Aprosenf, but thats not what i want.

There are thousands of places in my code where a Resource might get created, and if that same resource never gets de-allocated, I need to trace which function/class allocated it.

So, i''m attaching a stack trace to each resource, so that I can, at the end of the program, see which resources werent deallocated, and why...

The "Call Stack" window doesnt help me because, although i can breakpoint into the code each time a resource is created, at that point i dont know if it will be deallocated correctly, and theres no point in putting a breakpoint on the destructor, because it doesnt get called for non-deallocated resources..

Jester Says: Visit Positronic Dreams![Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"I say we take off and nuke the entire site from orbit. It''s the only way to be sure."
Wouldn''t it just be easier to use the __FUNCTION__, __FILE__ and __LINE__ macros rather than messing with the stack dump?
quote:Wouldn''t it just be easier to use the __FUNCTION__, __FILE__ and __LINE__ macros


I use this for a lot of my debugging... build in additional parameters in the CreateResource() type function that includes the above macros..

Or simply give it a unique ID number that you can track (combine this with a log file and you''re sorted).

That way, when you detect your leak, you output its ID and/or macros; that way you should be able to pinpoint the culprit

hth
Jack

<hr align="left" width="25%" />
Jack Hoxley <small>[</small><small> Forum FAQ | Revised FAQ | MVP Profile | Developer Journal ]</small>

quote:Wouldn''t it just be easier to use the __FUNCTION__, __FILE__ and __LINE__ macros rather than messing with the stack dump?
Correct me if i''m wrong, but doesnt that tell us where we are now? I want to know what function called us, so...

The stack trace tool im doing, if done right will also allows me to trace back from dlls, etc, which that cant do...


Jester Says: Visit Positronic Dreams![Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"I say we take off and nuke the entire site from orbit. It''s the only way to be sure."
quote:Original post by pentium3id
quote:Wouldn''t it just be easier to use the __FUNCTION__, __FILE__ and __LINE__ macros rather than messing with the stack dump?
Correct me if i''m wrong, but doesnt that tell us where we are now? I want to know what function called us, so...
So record where we are when we''re created. C++ isn''t introspective.
What if I want to know who called my caller?

This would lead to either a lot of code change or a mess of macros...

The Stack Trace code is almost finished anyway, maybe i''ll do a short Article for GameDev...

Jester Says: Visit Positronic Dreams![Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"I say we take off and nuke the entire site from orbit. It''s the only way to be sure."
Thats going to be impossible to read once name mangling gets ahold of it. Look up StackWalk64 in MSDN.
--God has paid us the intolerable compliment of loving us, in the deepest, most tragic, most inexorable sense.- C.S. Lewis

This topic is closed to new replies.

Advertisement