Module state data problem

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   When tracking a popup menu, we are finding that the code can call LoadImage on one of the theme objects. When it does, it creates an image object (in my case CXTPOffice2007Images object).

The image object is derived from CCmdTarget. When created, CCmdTarget obtains the current module state data pointer and directly stores it in instance data.

Then the CJ code that created the image object stores the object in an array. Later when the toolkitpro DLL unloads, all of these objects are disposed of.

So now we have a race condition where the order that DLLs unload becomes an issue. If the module that was active when the image was created is unloaded before the toolkitpro module, MFC can crash when the CCmdTarget object is given its release from the codejock images (removeall?) method.

Shouldn't the CodeJock code make sure that if it creates and stores a CCmdTarget based CodeJock object that before creating the object the codejock module state should be made the active module state? Otherwise, how can we robustly prevent crashes during shutdown?

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 899	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Topic: Module state data problem Posted: 05 June 2008 at 2:52pm
	When tracking a popup menu, we are finding that the code can call LoadImage on one of the theme objects. When it does, it creates an image object (in my case CXTPOffice2007Images object). The image object is derived from CCmdTarget. When created, CCmdTarget obtains the current module state data pointer and directly stores it in instance data. Then the CJ code that created the image object stores the object in an array. Later when the toolkitpro DLL unloads, all of these objects are disposed of. So now we have a race condition where the order that DLLs unload becomes an issue. If the module that was active when the image was created is unloaded before the toolkitpro module, MFC can crash when the CCmdTarget object is given its release from the codejock images (removeall?) method. Shouldn't the CodeJock code make sure that if it creates and stores a CCmdTarget based CodeJock object that before creating the object the codejock module state should be made the active module state? Otherwise, how can we robustly prevent crashes during shutdown?

Oleg Members Profile Send Private Message Find Members Posts Add to Buddy List Admin Group Joined: 21 May 2003 Location: United States Status: Offline Points: 11234	Post Options Post Reply Quote Oleg Report Post Thanks(0) Quote Reply Posted: 06 June 2008 at 1:08am
	Hi, Think you can call manually XTPOffice2007Images()->RemoveAll(); in some ExitInstance of your module.
	Oleg, Support Team CODEJOCK SOFTWARE SOLUTIONS

rdhd Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 13 August 2007 Location: United States Status: Offline Points: 899	Post Options Post Reply Quote rdhd Report Post Thanks(0) Quote Reply Posted: 17 July 2009 at 6:56pm
	Oleg, Has V13 stopped storing the objects or at least quit waiting until dll unload to let them go?