#### Archived

This topic is now archived and is closed to further replies.

# debug - tracking function calls

This topic is 5832 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I''m interested in tracing calls through a program''s execution - for debugging purposes (C/C++). For example, if I''m in WinMain() then go into SetupRender() and then SetFOV(), and an error occurs in SetFOV() I''d like to error with a string of maybe "SetFOV->SetupRender->WinMain" (obviously there would be the actual error details as well, but its the function track I''m interested in right now). So, is there an efficient/easy way to accomplish this, possibly without having to manually add something to every function I write? Also, I''d only be doing this on debug builds but I guess that could be overcome by #ifdefs and the appropriate redefinitions. Thanks. -Mezz

##### Share on other sites
If you are using Microsoft VC++, then you already get this via the Call Stack debug window.

##### Share on other sites
That''s called a stack. One thing you can do is make a linked list, like so.
  class Node{ public: Node() { next=NULL; last=NULL; } Node *next; Node *last; char functionName[100];}

Then create functions to add nodes and delete nodes. Call an addnode function at the start of each function, and an remover at the end.

  int Foo(){ globalList->AddNode("Foo"); //blah blah blah globalList->RemoveNode("Foo");}

Then to print out the stack, you would do something like this. I used cout for simplicity here.

GetStackCout(Node* list)
{
Node* current = list;
while(current!=NULL)
{
cout << "->" << current->functionName;
current = current->next;
}
}

Tada, a printed stack list of all the functions you have gone in, in the order you entered them. The add function would just go the the last node in the list and dynamically allocate a new one. Simple enough.

A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."

##### Share on other sites
That sounds good,

But what can you do if your program get stuck in an infinitive loop?

##### Share on other sites
You could make it so if something like WRITE_STACK was defined, it saved the stack info to a file on entering each function. It would be slow, but then again it would also be only used during a debug session, right? Otherwise, a standard debug would lead you to the source of the infinite loop, so there would be no real need to use the stack info for that one. The stack info is more likely to be used when an assert fails or something. Anyway, I gotta go now. So I can''t answer anything for a while.

A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."

##### Share on other sites
Thanks for the replies.

MonkeyChuff: I know - but somebody (i.e. a tester) who is running a debug build and doesn''t have the compiler, doesn''t get such a window.

ATronic: You''re solution is viable, but I was looking for something that perhaps didn''t require manually adding a log line of the entry/exit of the function.

You''ve also hit it home with the assert() failure - that is what I intend to use this for.

-Mezz

##### Share on other sites
I''m afraid you may need to put entry exit point declarations. It''s not such a big deal really, fairly easy. Why don''t you want to?

A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."

##### Share on other sites
It isn''t really that I don''t want to, I just thought there must be some kind of approach that provides such functionality - I mean I''d like to pretend I understand the StackWalk() function but I don''t.

-Mezz

##### Share on other sites
StackWalk?

A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."

##### Share on other sites
Yes there is a function called StackWalk() - it''s in MSDN if you search for it.

As I said, I don''t understand it a great deal but I think it can be used for tracing. Maybe.

-Mezz

##### Share on other sites
Woa. That function looks like the spawn of hell. I would stick to making your own. I for one attempt to stay away from windows based functions when it''s so easy to make your own.

A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."

##### Share on other sites
I think I might try both...

Simply because understanding and using that function seems like a challange, and rolling your own is always fun too.

Cheers,

-Mezz

##### Share on other sites
That sounds like a good idea. It''s always good to learn more whenever possible. I wish you the best of luck in getting the desired results. Happy coding!

A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."

##### Share on other sites

1) Make sure that you use macros, so that you can turn the enter/exit calls off in the final release. Otherwise, they will be a huge penalty.

2) Realize that the program may run MUCH slower. I''ve seen similar mechanisms used, and depending on how much work you do in the enter/exit call, it can make the program many times slower.

3) Make sure to get all the exit points, else you may have very unhappy results. You can guard against this by passing the routine name into both the enter and exit macros, and testing the exits to make sure they match the top of the stack.

4) Exceptions are a problem. Decide how you want to handle them. I would suggest against trapping exceptions in all routines in order to pop the stack. Instead, you may have to either have a special exception handler, or pop the stack to match the given exit.

Stack walking would be more foolproof, and less overall work, but requires pretty intense OS/compiler-specific programming.

##### Share on other sites
The way I have this kind of thing set up in my code is fairly good. Mine has a controller class and a node class. The controller has a pointer to the last node to allow fast additions. Exit takes longer than entry in mine, but I have it set up to only keep stack info when DEBUG2 is defined. The same goes for asserts, which are pre-processed out if it isn''t defined. Simple to implement, and VERY handy. Anyway, as I said, best of luck to you.

A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."

##### Share on other sites
quote:

Stack walking would be more foolproof, and less overall work, but requires pretty intense OS/compiler-specific programming.

This is no lie. MSDN, Feb 99 BugSlayer column implements what we''ve been discussing.
It''s hard to read, shall we say.

-Mezz