Re: Thread deadlock inside CString::AllocBuffer and sudden crashes

The failure to call AFX_MANAGE_STATE for a non-extension DLL could have consequences,
depending on what you are actually doing. In general, I believe it is good practice.
There are several pieces of state being managed, besides the resources, such as the
internal MFC maps.

Note that if you use static linking you have new and more wondrous problems if you let any
objects escape from your server in a form that can be manipulated directly by the user.
Such as letting the user delete them.

Deadlock should not occur unless you are doing non-canonical locking, in which case it
WILL occur. So you need to watch out for multiple locking sequences (sequences that can
lock two or more items in sequence). A thread that locks an object instance A and then
releases it, then locks an object instance B and releases it, cannot be subject to
deadlock, but one that locks A and then locks B has the potential for deadlock if any
sequence of code anywhere at any time can lock B then lock A.

How did you determine it was "deadlock" as opposed to, say, an infinite loop (or one that
was just very, very long)?
joe

On Thu, 26 Apr 2007 15:03:53 -0500, rajayan <rajayan.2po8un@xxxxxxxxxxxxxxxxxxxxx> wrote:


Am facing a issue similar to what we have under
[url]http://www.codecomments.com/archive372-2005-11-706874.html[/url]

I work for a imaging system software and modules are a mixture of pure
ATL dll, "ATL using MFC" components, COM EXE servers, regular MFC dll,
MFC EXE and extension MFC dlls.

Now that we are towards the *** end of the project, we are getting
occasionally hit by sudden crashes where our top level exception handler
is not even able to come into play and create the required .dmp file. We
also are seeing deadlock cases like the link I have mentioned above.

One interesting thing I found yesterday is the following

We have a MFC document view architecture based EXE component. This in
turn has couple of "ATL using MFC" components. These ATL components in
turn makes call to a MFC extension dll.

I realized that we are not following all the rules as described under
[url]http://support.microsoft.com/kb/q173974/.[/url] For our "ATL using
MFC" components. Basically none of our COM interface methods and COM
eventsink methods are using the AFX_MANAGE_STATE at all. Both COM
interface methods and the eventsink methods in turn uses MFC.

I would like to know how serious could this issue be. Could this lead
to issues as described under
[url]http://www.codecomments.com/archive372-2005-11-706874.html.[/url]
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Quantcast