|
|
You're in the
visual studio .net debugging
group:dbghelp / stackwal64 / xp sp2
visual studio .net debugging:
Hello,
I saw another post about problems after installing windows xp sp2 but none of this post looks like my problem. I have some code used to compute the call stack trace (for exemple to help to find and fix memory leaks). But since sp2 this code does no work. I am doing something like this for (uint32 i=0; StackWalk64(IMAGE_FILE_MACHINE_I386, handle, hThread, &sf, 0, 0, SymFunctionTableAccess64, SymGetModuleBase64,0);i++) { // TODO check this test. if (!sf.AddrFrame.Offset || !sf.AddrReturn.Offset) { return true; } if (!GetFunctionDebugInfo()) { return false; } } and in GetFunctionDebugInfo I use SymFromAddr, SymGetLineFromAddr64, ... Since SP2 the loop for stop at the first iteration in the test where sf is tested. If I remove this test the GetFunctionDebugInfo failed when I call SymGetLineFromAddr64. I am not very sure of my code but it was working before sp2. What is very strange is that I use the dbghelp library and include delivered with Debugging Tools for Windows. The version of DbgHelp is 6.3.17.0 but the one delivered with sp2 in system32 is 5.1.2600.2180. I do not link with DbgHelp so I (must be) am sure of the version I use. Some got any idea ?
Hi Nicolas, Sorry, I haven't had time to look at it until yesterday ... [quoted text, click to view] > I have some code used to compute the call stack trace (for exemple to > help to find and fix memory leaks). But since sp2 this code does no work. > Have you managed to resolve it already? [quoted text, click to view] > What is very strange is that I use the dbghelp library and include > delivered with Debugging Tools for Windows. The version of DbgHelp is > 6.3.17.0 but the one delivered with sp2 in system32 is 5.1.2600.2180. > > I do not link with DbgHelp so I (must be) am sure of the version I use. > So, which version is actually used? (6.3.17 or 5.1?) Regards, Oleg
[quoted text, click to view] > Hi Nicolas, > > Sorry, I haven't had time to look at it until yesterday ... Ok ... it is not a problem but I am very happy you answer me 'cos you alwasy got the good answer to my question :) [quoted text, click to view] >>I have some code used to compute the call stack trace (for exemple to >>help to find and fix memory leaks). But since sp2 this code does no work. >> > > > Have you managed to resolve it already? no :( [quoted text, click to view] >>What is very strange is that I use the dbghelp library and include >>delivered with Debugging Tools for Windows. The version of DbgHelp is >>6.3.17.0 but the one delivered with sp2 in system32 is 5.1.2600.2180. >> >>I do not link with DbgHelp so I (must be) am sure of the version I use. >> > > > So, which version is actually used? (6.3.17 or 5.1?) me I used the 6.3.17 which is located in the same directory as my executable and I load it using LoadLibrary (with an absolute path to be sure to load this dll). So I do not link with DbgHelp to be sure to use the version I want. But even doing this since I updated to SP2 my generation of the callstack fail. If i launch the same executable under win2k or winxp sp1 there is no problem. [quoted text, click to view] > Regards, hop you've got an idea of my problem ... [quoted text, click to view] > Oleg >
Try this sample file: http://www.debuginfo.com/examples/src/StackWalk.cpp Will it work on XP SP2? (Of course, it needs to be built against the latest Dbghelp.h and .lib, as well as the latest Dbghelp.dll should be in the same directory with it). Oleg
[quoted text, click to view]
Oleg Starodumov wrote: > Try this sample file: > http://www.debuginfo.com/examples/src/StackWalk.cpp > > Will it work on XP SP2? yes ... I put the DbgHelp 6.3.17 neer the exe but the exe was linked without any changes in include/lib directories so I supposed it linked with the standard version of windows. so it works so I think I need to find the difference between this sample and my code :( [quoted text, click to view] > (Of course, it needs to be built against the latest Dbghelp.h and .lib, > as well as the latest Dbghelp.dll should be in the same directory with it). nicolas [quoted text, click to view] >
> Oleg > > > >
[quoted text, click to view] > yes ... > I put the DbgHelp 6.3.17 neer the exe but the exe was linked without any > changes in include/lib directories so I supposed it linked with the > standard version of windows. in fact it works also if I linked with the sdk of the 6.3.17 ...
[quoted text, click to view] > so I look for differences between my code and the sample Take a look at the way STACKFRAME64 structure is initialized. I think that is the difference that makes the sample work on SP2. Oleg
It is me again ... [quoted text, click to view] > Take a look at the way STACKFRAME64 structure is initialized. > I think that is the difference that makes the sample work on SP2. You're right the problem seems to come from here but I steel have a problem. I try to explain: In my code again initialize STACKFRAME64 using a CONTEXT I get calling GetThreadContext. In your code your are using the intrinsic _ReturnAddress and some asm to get esp and ebp. when I compare context.Esp/context.Ebp and esp/ebp (retrieved using asm) they are the same. But when I compare context.Eip with the value returned by _ReturnAddress they are different. So I try to use it instead of context.Eip. But the problem is not solved. The first call to StackWalk64 is ok (if i try to retrieve the symbol I can retrieve the name of the function) but the second time I call StackWalk64 stackFrame.AddrFrame.Offset and stackFrame.AddrReturn.Offset are null (equal to 0). I really do not understand what happened ? First the fact that context.Eip != ReturnAddress is very strange. But it is not the solution at my problem. Another questions for you oleg : - why do you get eip/esp/ebp using intrinsic and asm instead of getting the CONTEXT ? - why do you use #pragma optimize ( "", off ) ? [quoted text, click to view] > Oleg
[quoted text, click to view] > when I compare context.Esp/context.Ebp and esp/ebp (retrieved using asm) > they are the same. But when I compare context.Eip with the value > returned by _ReturnAddress they are different. So I try to use it > instead of context.Eip. But the problem is not solved. the thing which is very strange is that context.Eip and _ReturnAddress are also different under winxp sp1. but under winxp sp1 all is ok. The fact is that I am not really an asm/register guru.
[quoted text, click to view] > Have you compared them on XP SP2? > On my test SP2 system the EBP returned by GetThreadContext > is not the same, actually it is far below than the EBP of the function that called it. > (And therefore I assume that it is not safe to ask StackWalk64 to walk the stack > frames which can be overwritten by the code that calls StackWalk64 and analyzes > its output). > > That is why I try to get the initialization data for STACKFRAME64 myself, > without relying on GetThreadContext. I think I do not completly understand why you are doing the initialization yourself ... [quoted text, click to view] > > What happens with your code if you set up STACKFRAME64 exactly as > in the example? ok ... in my first I make a mistake ... if I use the three value (eip/ebp/esp) the same as in your sample all is ok ... so my problem is because I use GetThreadContext and CONTEXT. I'll try to understand your explaination about why you are getting the values by your self. thanks again .... Do you know something about a difference in GetThreadContext between SP1/SP2 ? Perhaps I'll contact microsoft via MSDN.
[quoted text, click to view] > In my code again initialize STACKFRAME64 using a CONTEXT I get calling > GetThreadContext. In your code your are using the intrinsic > _ReturnAddress and some asm to get esp and ebp. > > when I compare context.Esp/context.Ebp and esp/ebp (retrieved using asm) > they are the same. Have you compared them on XP SP2? On my test SP2 system the EBP returned by GetThreadContext is not the same, actually it is far below than the EBP of the function that called it. (And therefore I assume that it is not safe to ask StackWalk64 to walk the stack frames which can be overwritten by the code that calls StackWalk64 and analyzes its output). That is why I try to get the initialization data for STACKFRAME64 myself, without relying on GetThreadContext. What happens with your code if you set up STACKFRAME64 exactly as in the example? [quoted text, click to view] > But when I compare context.Eip with the value > returned by _ReturnAddress they are different. EIP returned by GetThreadContext should be somewhere inside GetThreadContext. EIP returned by _ReturnAddress belongs to the CStackWalk::Walk(). [quoted text, click to view] > - why do you get eip/esp/ebp using intrinsic and asm instead of getting > the CONTEXT ? Because I think the context returned by GetThreadContext on SP2 is not safe to use for stack walking, because the stack walking code writes over the same stack space it attempts to analyze. [quoted text, click to view] > - why do you use #pragma optimize ( "", off ) ? > To disable optimizations in CStackWalk::Walk(), and FPO optimizations in particular, so that I can be sure that EBP register really stores the frame base pointer. Oleg
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |