Исходники.RU - Информационный сервер для программистов: исходники со всего света.

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

| Вернуться в корень Архива |