You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by bu...@apache.org on 2001/09/05 23:45:24 UTC
[DO NOT REPLY: Bug 3444] New:
initialise/uninitialise platform problem
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: xerces-c-dev@xml.apache.org |
+ | Reported By: mark@npsl.co.uk |
+ +----------------------------------------------------------------------------+
+ | 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 mark@npsl.co.uk, although I will try to
+ check back here.
+
+ Thanks,
+
+ Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org