Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Donate
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ _ReturnAddress() is my favorite compiler intrinsic

I'm sick with a cold at the moment, so I'll blog twice today. It'll somewhat make up for my not having blogged the entire month.

Visual C++ has a compiler intrinsic called _ReturnAddress() that gives the return address of the calling function. It exists back to at least VC6, but wasn't documented until VC7. This has become my favorite intrinsic, because you can do lots of evil debugging hacks with it, and it's very fast. There's a known issue with this intrinsic that if the function is inlined the intrinsic returns the return address above the inline site, but I've found that's actually sometimes desirable behavior.

Got a memory leak and the caller didn't provide file/line information when allocating? Overload operator new, call _malloc_dbg() with the return address as the line number, and track down the call site from the leak report. I use this in shutdown of debug builds of VirtualDub, along with DbgHelp, to print names of guilty functions that leaked memory without requiring specially tagged operator new() calls. I also lookup the first four bytes of the memory block to check if it's a virtual method table pointer, which then also gives the type of object leaked.

If you are doing COM-style (AddRef/Release) reference counting, you've probably discovered what a pain it can be to track down a leak from a missing Release() call. It used to be that I'd do this by capturing and manually matching the call stacks of every AddRef() and Release() on a particular class, a very slow and laborious technique. VS2005 makes this a little easier because you can sometimes use tracepoints with $CALLSTACK, but it's still slow. My new favorite technique is to maintain a global map of all AddRef() and Release() callers by _ReturnAddress() and compile call counts by calling site. You can then quickly eliminate the smart pointer code quickly as long as the totals add up and then determine which call sites are involved and who screwed up manual reference counting.

My latest exploit involving _ReturnAddress() was to deal with a chatty DLL that was spewing to Win32 debug output, making it unusable for anything I was trying to debug. Solution: Patch the export for OutputDebugString() at runtime and redirect it to a function that used _ReturnAddress() to look up the calling DLL. Now I can filter debug traces by DLL.

_ReturnAddress() quickly becomes inadequate for more complex scenarios because it only gives you one level of stack walk. That's often sufficient, though, and since a real stack walk is so much more expensive (and on x86, unreliable) I find it a useful shortcut.

Comments

Comments posted:


gcc calls this __builtin_return_address(0).

Glenn Maynard - 10 01 08 - 11:45


Get well soon!

DJT-Rew - 12 01 08 - 17:00


There's pretty much a built-in tool in VS for this type of work - check out trace points, e.g. at http://blogs.msdn.com/ms_joc/archive/200..
specifically the $CALLER/$CALLSTACK keywords, and the (pretty neat) macro environment.
can't say if it solves your 3rd scenario, though.. maybe the macro caps are rich enough. dunno.

Ofek - 23 01 08 - 03:57


I love tracepoints myself, but they have a fairly big drawback: tracepoints are just breakpoints with different handling. That means that every time your program hits a tracepoint, the OS stops the thread, sends a message to the debugging process, the debugging engine gets the message, executes the tracepoint function, calls ContinueDebugEvent(), and finally the OS resumes the thread. Combined with the mindblowing speed of the VS2005 IDE at displaying trace output -- which is admittedly faster than VS2003, but still loads slower than VC6 and a boatload slower than NTSD -- and frequently hit tracepoints can make your app run very, very slow. If you do a lot more tracking than logging, _ReturnAddress() is orders of magnitude faster when you can use it.

Phaeron - 23 01 08 - 23:44

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.