New MFC 4.2 deadlock problem
michael berganovsky -- michael_berganovsky@ibi.com Wednesday, August 21, 1996 Environment: MSVC 4.2, NT 3.51 SP4 We are building single threaded OLE intensive MFC application using MFC 4.2 DLL. We are running into very serious problem which we believe is attributable to MFC 4.2 implementation. APPLICATION USING MFC 4.2 and OLE2 HANGS!!! To make things simple - whenever our application makes call to a functions from OLE32.DLL, OLEAUT32.DLL or OLEPRO32.DLL for the first time it ends up in GetProcAddress for the specified function. (see oledata.cpp and oleimpl.h in MFC sources). At least in WinNT (and according to Matt Pietrek in Win95) GetProcAddress acquires process' critical section. In MFC 4.2 Microsoft added new code in DLLMain implementation which may conflict with GetProcAddress (or any other synchronized on process' critical section calls). In shared build of MFC this code is linked into MFC42.DLL and in debug build into MFC42D.DLL and MFCO42D.DLL (see dllmodul.cpp and dllole.cpp in MFC sources). In our case DllMain from MFCO42D.DLL or MFC42.DLL got called with DLL_THREAD_DETACH when some service thread (created by KERNEL32) other then our main thread exits. It is guarded by process critical section. But our main thread is running and calls some function from OLEAUT32.DLL for example VariantClear, which ends up in GetProcAddress( hInstance, "VariantClear" ), which in turn blocks on acquiring process critical section. Now main thread is waiting for DllMain to return to release critical section. But inside of DllMain AfxOleTermOrFreeLib calls CoFreeUnusedLibraries which tries to SendMessage to the window created in main thread which is blocked on process critical section. That does it. We hang! It looks like ANY application using shared MFC 4.2 or ActiveX components linked with MFC 4.2 is in danger! --Good luck
Mike Blaszczak -- mikeblas@nwlink.com Sunday, August 25, 1996 At 12:35 PM 8/21/96 edt, you wrote: > Now main thread is waiting for DllMain to return to release critical > section. But inside of DllMain AfxOleTermOrFreeLib calls > CoFreeUnusedLibraries which tries to SendMessage to the window created > in main thread which is blocked on process critical section. That does > it. We hang! > It looks like ANY application using shared MFC 4.2 or ActiveX > components linked with MFC 4.2 is in danger! This problem has been fixed for the MFC 4.2a patch. .B ekiM http://www.nwlink.com/~mikeblas <--- trip report central 1995 Honda VFR750F (Serial number 00050!) 4 Corners 1996! 1987 Yamaha FZ700 (damaged) AMA, HRC, VFROC These words are my own: I do not speak for Microsoft.
| Вернуться в корень Архива |