Re: Sharing a RO std::list between 2 threads & Crash in _Orphan_ptr()
On Sun, 30 Mar 2008 17:57:16 +0200, "h.wulff" <zuhause@aol.com> wrote:
Hi!
I've a shell extension that adds a tab to the file property dialog. My
tab shows some additional file information. I hold the list of files
besides my additional file information in a std::list container.
When my tab is about to be shown I start a separate thread to scan the
files for the file information by iterating through the std::list
container and adds file information to each element. For each scanned
element of the std::list container the scan thread sends a update window
message to update the file information of the tab. The message receiver
iterates through the std::list container as well. Access to each element
of the std::list container is controlled by a semaphore. Access to the
std::list container itself is not controlled in any way. After all
elements of the std::list container has been scanned the thread exits.
The release version of my shell extension works fine. But the debug
version crashes on calling erase(), clear() or remove() in _Orphan_ptr()
of vc\include\list:1233 (VS 2005):
if ((*_Pnext)->_Ptr == _Myhead || _Ptr != 0 && (*_Pnext)->_Ptr != _Ptr)
Where _Pnext->_Ptr is NULL
But the crash *only* happens when the scan thread has accessed the
std::list container, otherwise not. _Orphan_ptr() is only available when
_HAS_ITERATOR_DEBUGGING is set. (Which is probably the case for debug
environment)
According to <http://msdn2.microsoft.com/en-us/library/c9ceah3b.aspx>:
"A single object is thread safe for reading from multiple threads.
[...]" so my design should be the problem. The std::list container is
only modified once at start of my shell extension. Especially not when
the scan thread and the message receiver accessing the container.
Any comments or hints are welcome!
When are the functions you mentioned, "erase(), clear() or remove()",
called? Also, I don't see why you use a semaphore; it seems a mutex
(CRITICAL_SECTION or HANDLE-based) would be appropriate. Finally, here are
a couple of suggestions for shell extensions in general:
1. Use SHGetInstanceExplorer to keep the host process alive while your
extension is active. (Ignore what the documentation says about it
"succeeding only if it is called from within an Explorer.exe or
Iexplorer.exe process;" it's equally important to use it for programs like
my runmenu, http://www.eluent.com/runmenu.htm.)
2. Don't link dynamically to the CRT and other libraries, because your DLL
is being loaded into an environment you don't control, and it may end up
sharing the CRT with other extensions. If this happens, even if you're
careful not to mess up their CRT state, they can still mess up yours.
--
Doug Harrison
Visual C++ MVP