GPF in TRACE
SCS.007@mch.scn.de Tuesday, December 31, 1996 Environment : VC++ 1.52, Win 3.11, Intel 486 Hi folks!, Happy New Year! This is VERY URGENT. I've developed a DLL ( _AFXDLL ). I wrote a sample application which tests it. Everything's fine. Now this DLL has to be integrated to other apps. Compilation, Linking - No problems. Now the moment, the app makes a call to the DLL, and the first TRACE statement is encountered, I get a GPF. I really don't know whats happening. But when I substitue TRACE statements by OutputDebugString, it works fine. But I need the DEBUG version working. Any suggestions are welcome. Thanks and regards chandru.
Mike Blaszczak -- mikeblas@nwlink.com Tuesday, December 31, 1996 At 03:06 12/31/96 GMT, SCS.007@mch.scn.de wrote: >Environment : VC++ 1.52, Win 3.11, Intel 486 >Happy New Year! This is VERY URGENT. You should contact Microsoft's product support services, or get someone from the Solution Provider's directory to come and look at your code. MFC-L is designed for peer-to-peer support, and as such can't guarantee a correct and timely answer. It isn't the place for urgent requests. >I've developed a DLL ( _AFXDLL ). I >wrote a sample application which tests it. Everything's fine. >Now this DLL has to be integrated to other apps. Compilation, Linking - No >problems. Now the moment, the app makes a call to the DLL, and the first >TRACE statement is encountered, I get a GPF. Where? At what line of what function in which module? What does the stack dump in the debugger say? Who called who with what parameters to get you where you are? .B ekiM http://www.nwlink.com/~mikeblas/ I'm afraid I've become some sort of speed freak. These words are my own. I do not speak on behalf of Microsoft.
SCS.007@mch.scn.de Wednesday, January 01, 1997 >> Where? At what line of what function in which module? What does >> the stack dump in the debugger say? Who called who with what >> parameters to get you where you are? >> ..B ekiM >> http://www.nwlink.com/~mikeblas/ >> I'm afraid I've become some sort of speed freak. >> These words are my own. I do not speak on behalf of Microsoft. Hi Mike!, Sequence of Calls. CAsyncSocket::Create CAsyncSocket::Socket() CAsyncSocket::AttachHandle() CAsycnSocket::CreateEx() PreCreateWindow() - // I try stepping in - it says there is no src line // debugging info. I press F5 - *_GPF_* - and the call stack shows four calls to USER!() AfxWndProc() _AfxCallWndProc() _AfxTraceMsg() AfxTrace() // and then the following func. extern "C" void CDECL AfxTrace(LPCSTR pszFormat, ...) { va_list args; va_start(args, pszFormat); (_AfxGetAppDebug()->lpfnTraceV)(pszFormat, args); // GPF here. } Please enlighten me if you need any other info. ///****************** Relevant Project settings for the DLL CFLAGS_COMMON_D = /nologo /G2 /W4 /Od /D "_DEBUG" /I $(PInclude) CFLAGS_COMMON_R = /G2 /W4 /Zd /Od /D "NDEBUG" /I $(PInclude) LFLAGS_COMMON_R = /NOD /NOE /PACKC:61440 /ONERROR:NOEXE \ /MAP:FULL /LINE LFLAGS_COMMON_D = /NOD /NOE /PACKC:61440 /ONERROR:NOEXE \ /CO /MAP:FULL /LINE LIBS_COMMON_R = oldnames libw commdlg shell ddeml LIBS_COMMON_D = oldnames libw commdlg shell ddeml CFLAGS_D_WDLL = /nologo /G2 /W3 /Zi /ALw /Od /D "_DEBUG" /D "_AFXDLL" /D "CTX_VERSION" /FR /GD /GEf /Fd"DLLVER.PDB" CFLAGS_R_WDLL = /nologo /W3 /ALw /O1 /D "NDEBUG" /D "_AFXDLL" /D "CTX_VERSION" /FR /GD /GEf LFLAGS_D_WDLL = /NOLOGO /NOD /NOE /PACKC:61440 /ALIGN:16 /ONERROR:NOEXE /CO /MAP:FULL LFLAGS_R_WDLL = /NOLOGO /NOD /NOE /PACKC:61440 /ALIGN:16 /ONERROR:NOEXE /MAP:FULL LIBS_D_WDLL = mfc250d mfcn250d oldnames libw ldllcew commdlg.lib shell.lib toolhelp.lib LIBS_R_WDLL = mfc250 mfcn250 winsock oldnames libw ldllcew commdlg.lib shell.lib RCFLAGS = /nologo RESFLAGS = /nologo // ******************* Relevant proj settings for the app DUUPD_CFLAGS = $(CFLAGS_COMMON_D) $(CFlags_Common_Exe) \ /D "OSS_VERSION" /D "JPOLA" /D "_AFXDLL" /Zi DUUPD_LFLAGS = $(LFLAGS_COMMON_D) /ALIGN:16 /STACK:10240 DUUPD_LIBS = mfc250d $(LIBS_COMMON_D) mfcd250d llibcew \ odbc SCCFGA00 SCIPCA00 SCDATA00 SCSRVA00 SEENGA00 SZENGA00 \ SCHFMA00 SCRECA00 LAMX0A0H DMUDLQ00 DMNETQ0H IDEXEA00 DLLVER !ELSE ! IFDEF RELEASE_WITHOUT_TRACE DUUPD_CFLAGS = $(CFLAGS_COMMON_R) $(CFlags_Common_Exe) \ /D "OSS_VERSION" /D "JPOLA" /D "_AFXDLL" /D "RELEASE_WITHOUT_TRACE" ! ELSE DUUPD_CFLAGS = $(CFLAGS_COMMON_R) $(CFlags_Common_Exe) \ /D "OSS_VERSION" /D "JPOLA" /D "_AFXDLL" ! ENDIF DUUPD_LFLAGS = $(LFLAGS_COMMON_R) /ALIGN:16 /STACK:10240 DUUPD_LIBS = mfc250 $(LIBS_COMMON_R) mfcd250 llibcew \ odbc SCCFGA00 SCIPCA00 SCDATA00 SCSRVA00 SEENGA00 SZENGA00 \ SCHFMA00 SCRECA00 LAMX0A0H DMUDLQ00 DMNETQ0H IDEXEA00 DLLVER !ENDIF
Mike Blaszczak -- mikeblas@nwlink.com Wednesday, January 01, 1997 At 08:02 1/1/97 GMT, SCS.007@mch.scn.de wrote: >>> Where? At what line of what function in which module? What does >>> the stack dump in the debugger say? Who called who with what >>> parameters to get you where you are? >Sequence of Calls. > >CAsyncSocket::Create > CAsyncSocket::Socket() > CAsyncSocket::AttachHandle() > CAsycnSocket::CreateEx() > PreCreateWindow() - // I try stepping in - it says there is no src line > // debugging info. >I press F5 - *_GPF_* - and the call stack shows > >four calls to USER!() >AfxWndProc() > _AfxCallWndProc() > _AfxTraceMsg() > AfxTrace() // and then the following func. > >extern "C" void CDECL >AfxTrace(LPCSTR pszFormat, ...) >{ > va_list args; > va_start(args, pszFormat); > > (_AfxGetAppDebug()->lpfnTraceV)(pszFormat, args); // GPF here. >} > >Please enlighten me if you need any other info. I'm still waiting for the information I asked for the first time: who passes what parameters to whom? You showed the stack trace, but you didn't show who was passing what parameters. Is _AfxGetAppDebug() returning NULL? If so, it sounds like the problem you're having is because you've not (or not yet) initialized MFC when you're trying to call Create() on a CAsyncSocket. Since you didn't show who called CAsyncSocket::Create() (which is also part of your stack trace), I still don't think anyone could make a diagnosis. .B ekiM http://www.nwlink.com/~mikeblas/ I'm afraid I've become some sort of speed freak. These words are my own. I do not speak on behalf of Microsoft.
Scott Colestock -- scolestock@wavefront.com Thursday, January 02, 1997 >extern "C" void CDECL >AfxTrace(LPCSTR pszFormat, ...) >{ > va_list args; > va_start(args, pszFormat); > (_AfxGetAppDebug()->lpfnTraceV)(pszFormat, args); // GPF here. >} >Please enlighten me if you need any other info. Is the TRACE statement that causes this problem your own or MFC's? If = it is your own, have you double & triple checked that your = variable-length argument list matches your format specifier? - Scott Colestock (scolestock@usa.net)
David Little -- dlittle@equinoxcorp.com Thursday, January 02, 1997 Is the TRACE statement that causes this problem your own or MFC's? If = =3D it is your own, have you double & triple checked that your =3D variable-length argument list matches your format specifier? AND, have you checked that you cast each and every variable to the type = specified in the TRACE statement, AND, have you counted the format = specifiers and the variables? Did you cast a CString to LPCSTR for the = %s spec? This kind of stuff will wreak havoc on a TRACE..... David
| Вернуться в корень Архива |