PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL BE LOST SOMEWHERE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3444 *** shadow/3444 Wed Sep 5 14:45:23 2001 --- shadow/3444.tmp.12043 Wed Sep 5 14:45:23 2001 *************** *** 0 **** --- 1,56 ---- + +============================================================================+ + | initialise/uninitialise platform problem | + +----------------------------------------------------------------------------+ + | Bug #: 3444 Product: Xerces-C++ | + | Status: NEW Version: 1.5 | + | Resolution: Platform: Other | + | Severity: Major OS/Version: Windows NT/2K | + | Priority: Other Component: Utilities | + +----------------------------------------------------------------------------+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + +----------------------------------------------------------------------------+ + | URL: http://www.npsl.co.uk | + +============================================================================+ + | DESCRIPTION | + There is an initialise/uninitialise platform problem with statically allocated + variables that use XMLDeleterFor to implement lazy deletion. For example, + gScannerMutex() contains a statically allocated which is checked by the + function at startup. Now if you: + + XMLPlatformUtils::Initialize(); + DOMParser* parser = new DOMParser; + delete parser; + XMLPlatformUtils::Terminate(); + XMLPlatformUtils::Initialize(); + DOMParser* parser = new DOMParser; + + then you get an invalid handle fault on the creation of the second DOMParser + (my example was slightly more complex than this but I believe it holds). The + reason is that the static variable in gScannerMutex is not, and cannot, be + reset by the call to XMLPlatformUtils::Terminate(). However, + XMLPlatformUtils::Terminate does clean up the lazy data. So on the second call + the mutex is no longer initialised, but the static variable /does/ point + somewhere so a new mutex is not created. The solution is (possibly) to make + these static variables global that are reset by XMLPlatformUtils::Terminate. + (Yeuch!). I haven't thought of a more elegant one. Also, there are a number + of examples of this kind of use of XMLDeleteFor (gMsgMutex springs to mind) - + I'm not too sure where they all are/would be however. + + Irrelevant background. Why would want I do this? Well, I /don't/ + deliberately. My component is a COM component created by IIS which uses the + DOM object directly. No problem here, but IIS eventually `unloads' my DLL, + i.e. calls DLLMain with DLL_PROCESS_DETACH. Here I call + XMLPlatformUtils::Terminate. Then the DLL is `reloaded' - another call with + DLL_PROCESS_ATTACH. AFAIKT the BSS segment for the DLL is not reinitialized + (eek!) which leads to the problem I have described above. However, I believe + that the problem can be abstracted to the above, which points to a slight + design error in the Initialize/Terminate sequence. To resolve my problem, I am + going to attempt the global variable/reset as described; comments would be + welcome, especially on how to submit the modified code or a better way of doing + this. I would prefer direct mail to [EMAIL PROTECTED], although I will try to + check back here. + + Thanks, + + Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
