Re: Access Violation using CCriticalSection in DLL
On Sat, 7 Apr 2007 11:12:18 -0600, "Brian Westcott" <bwestcott@shaw.ca>
wrote:
Sorry for the mangled description. The logger is actually a class that I
instantiate outside of the scope of my main program. CCriticalSection is
declared within the logger class. If I comment out calls to the logger in
the DLL, then the logger works OK once I return from the DLL, so lifetime
does not appear to be an issue.
I also am testing this by sending a very short message to the logger from
the DLL to ensure that I am not overrunning the Logger's buffer.
I have compiled evrything, including the DLL, with debug mode and
everything works when I run a debug version. When I execute the debug mode
without starting the debugger, it also works.
If I run the release mode of the main program with the debug version of the
DLL
There's your problem. In general, you can't expect to share C++ objects
between release and debug modules. Here, the layout of CCriticalSection
changes, which throws everything off. To see why, look inside <afxmt.h> at
the definition of CSyncObject, from which CCS derives. It contains:
#ifdef _DEBUG
CString m_strName;
virtual void AssertValid() const;
virtual void Dump(CDumpContext& dc) const;
#endif
This causes the debug and release versions to think the CRITICAL_SECTION
object contained in CCS resides in different locations in memory.
then the program fails with an access violation in the call to Lock().
I get a beak at the point in the dbugger and the stack trace is:
NTDLL!7c918fea()
NTDLL!7c90104b()
Logger::EnterLogCriticalSection(), which is declared as:
void EnterLogCriticalSection() {ccs.Lock();}
ccs is the instantiated CCriticalSection in the Logger class.
If I take a look at ccs, it appears normal, except that
ccs.m_sect.OwningThread = NULL;
That's normal for an unlocked CS.
Is there any other info I can give that might help?
This was a very good description.
--
Doug Harrison
Visual C++ MVP