 |
|
 |
Hello,
I think arguments are missing when displaying some error messages.
In ExtendedTrace.cpp, in line 318, 327, 386 and 418, there is messages with format specifications ("thread=0x%X") but no argument.
I think GetCurrentThreadId() is missing but may be I'm wrong.
It's a very good article anyway.
Thanks
Ludovic
|
|
|
|
 |
|
 |
The test app fails in FunctionParameterInfo at the check for callStack.AddrFrame.Offset != 0. I saw several messages on another message board with a similar problem, but no solution. VS6 XP sp2.
|
|
|
|
 |
|
 |
Sometimes, it doesn't work.
report error at "_tcschr( lpszParsed, _T(',') );"
change it like this "_tcschr( (char*)lpszParsed, _T(',') );"
Just do it at time, and live like a person on earth.
|
|
|
|
 |
|
 |
Hey thanks. I made my own downsized version of it to mimic .NET's __FUNCTION__ macro in VC++ 6.0; It's posted on the code project too.
|
|
|
|
 |
|
 |
I'm having a problem where all the symbols and line numbers are incorrect for my code. The symbols and line numbers are correct for the MFC libraries that are in the call stack. I do call EXTENDEDTRACEINITIALIZE and pass it a string that is the path of the directory that has my dll and pdb files.
|
|
|
|
 |
|
 |
Sorry, I'm using VC6SP4 on NT4SP6 and it doesn't work. Specifically, the call to SymGetSymFromAddr() always returns 487 (ERROR_INVALID_ADDRESS). If anyone knows why, post a reply, please. Thanks.
|
|
|
|
 |
|
 |
I'm having a similar problem. VC6 + platform SDK on Win2k. Some symbols get pulled OK, but most of the calls to SymGetSymFromAddr() return 487. Some of the objects I'm trying to debug are COM components and I'm wondering if something needs to be done differently for them. I can see the .DLL name for the COM components in the stack trace, but it doesn't show which function was called because of the error noted above (the COM components have been compiled with debug information in them). Anyone know how to fix this? Thanks!
|
|
|
|
 |
 | vc7  |  | Anonumus | 9:24 23 Mar '02 |
|
|
 |
|
 |
Yup, same here. Not working in VC++.NET 7.1.3088.
Sonork 100.41263:Anthony_Yio
|
|
|
|
 |
|
 |
not working for me either. StackWalk returns 'callStack.AddrFrame.Offset' as zero the second time around the loop so nothing ever gets printed. Any ideas anybody?
|
|
|
|
 |
|
 |
Look at the StackWalk example here:
http://win32.mvps.org/index.html
The reason is because you cannot dump the current thread's stack, you *must* spin off a worker thread to do that job for you.
|
|
|
|
 |
|
 |
in ExtendedTrace.h you have
#define STACKTRACEMSG( Msg ) StackTrace( Msg )
I think this should be
#define STACKTRACEMSG( Msg ) StackTrace( GetCurrentThread(), Msg )
because StackTrace is defined as void StackTrace( HANDLE, LPCTSTR );
Great code BTW
|
|
|
|
 |
 | Great Work  |  | Anonymous-5548735285423187423 | 10:43 28 Dec '01 |
|
 |
Some things about this great implementation:
It is linked against ImageHlp.lib (NT), but it should be linked against DbgHelp.lib,
which does the same thing for Win2000 and XP.
The code works on every WinOS, you just have to copy the DbgHelp.dll from Win2000,
no reg-settings are needed.
I use this code in my exceptions and I changed the code to load the dll only on demand.
You can't use it after the throw, you have to use it in the ctor of the exception.
It is VERY helpful to see the call stack when an exception occurs!
Thanks for your work,
CL
|
|
|
|
 |
|
 |
Function info and display of call stack doesn't work in the release build.
It is clear that when some symbols are missing, the function info is also
missing, but why does the call stack dump not work (count of functions
should be the same on every build)?
CL
|
|
|
|
 |
|
 |
You are using some functions from IMAGHLP.DLL that exist only on NT/2000. I'd suggest you to mention it.
|
|
|
|
 |
|
 |
Right, all is great, but to me the most trouble with the M$'s original TRACE was it's limitation to 512 characters. I really sucks when you want to trace large SQL queries etc.
What I don't get is why TRACE can not split the long string and print that.
I will have to take a look at it one day and make some fix...
|
|
|
|
 |
|
 |
that 512 limit really pisses me off too ... i got to the point of changing the mfc code and recompiling but then wondered if it would break something somewhere deep in the bowels of mfc ... is it as simple as letting the string (they dont use a cstring even) be declared as whatever[1024] and recompiling?
---
"every year we invent better idiot proof systems and every year they invent better idiots"
|
|
|
|
 |
|
 |
A MFC incompatible TRACE function can be written with using OutputDebugString.
The new trace function can accept (with paranthesis ...) as variable-argument parameters and can manipulate them with using vprintf functions. (Check out va_arg, va_end, va_start), format them with using vsprintf and print via OutputDebugString. They are easy to use and fun.
The limit of the character count is specified in vsprintf, so one can specify his/her own according to his/her taste. A limit is mandatory and in my opinion it is needed, think of a garbage read into a string buffer without NULLs. But I am so pissed of Assertions, too.
So, writing your own trace function is nothing more than combining a variable-argument formatting function and OutputDebugString API call.
Have several nice days
Mehmet
|
|
|
|
 |
|
 |
Hi Mehmet,
Actually the purpose of that article is not the non-MFC TRACE implementation.
I think the beaty was the stack dump or function parameter info
Regards,
Zoltan
Zolee
|
|
|
|
 |
|
 |
Here is my little trace function.
It works with MFC code and non-MFC code.
The main drawback with it is that even in release builds
The parameters are pushed and the function is called.
I suspect that with some creative macro writing this
can be overcome but I haven't worried much about it.
DllFunc void Trace( const char *format, ... )
{
#ifdef _DEBUG
va_list args;
char buf[ 1024 ]; // adjust size as needed
va_start( args, format );
vsprintf( buf, format, args );
va_end( args );
OutputDebugString( buf );
#endif // _DEBUG
}
Enjoy yourselves.
|
|
|
|
 |
|
 |
=) here is my <code> void dsf(const char *msg, ...) { #ifdef LOG va_list argp; char log[4096]; if ( msg != NULL) { va_start(argp, msg); (void) vsprintf(log, msg, argp); #ifdef _DEBUG OutputDebugStringA(log); #endif FILE* f=fopen(log_fname,"a"); fwrite(log,1,strlen(log),f); fclose(f); va_end(argp); } #endif } void dsf(const TCHAR *msg, ...) { #ifdef LOG va_list argp; TCHAR log[4096]; if ( msg != NULL) { va_start(argp, msg); (void) vswprintf(log, msg, argp); #ifdef _DEBUG OutputDebugString(log); #endif FILE* f=_wfopen(log_tfname,L"a"); fputws(log,f); fclose(f); va_end(argp); } #endif } </code>
|
|
|
|
 |