Marcus Webster wrote:
>
> I am trying to use nsAutoMonitor to protect some code from reentrancy,
> however I am being thwarted by some wierd problems that result in
> illegal memory accesses. (Platform: Windows 2K, MSVC 6.0, Mozilla 0.8
> code base)
>
> The code is basically as follows:
>
> nsresult
> CPackage::Init( nsIFile* pPackageFile )
> {
> nsresult rv = NS_OK;
>
> /* Create a monitor for controlling access to the file */
> m_pmonPackage = PR_NewMonitor();
> if( !m_pmonPackage ) return NS_ERROR_OUT_OF_MEMORY;
>
> nsAutoMonitor monitor(m_pmonPackage);
>
> /* Processing */
>
> }
>
> The monitor is created, OK the nsAutoMonitor appears to instantiate OK,
> but once the processing has finished the destructor of nsAutoMonitor
> fails, because the mMonitor member variable of nsAutoMonitor has
> miraculously become set to 1. N.B. m_pmonPackage is a member of the
> CPackage class.
>
> Any theories/suggestions would be appreciated
This is a good opportunity to explore the use of data watchpoints
in your debugger.
FWIW, you should be using nsAutoMonitor::NewMonitor and
nsAutoMonitor::DestroyMonitor
to create and destroy your monitors if they are to be used with
nsAutoMonitor. It is not clear to me that this would cause what
you see.
http://lxr.mozilla.org/seamonkey/source/xpcom/threads/nsAutoLock.cpp#68
Also, you say "protect from reentrancy". This is not going to
protect you from reentrance on the same thread. Does you code
have that danger? And, is there any code in what you don't show
that could cause deletion of 'this' before Init returns? That
would be bad.
John.
