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=3369 *** shadow/3369 Sat Sep 1 09:53:01 2001 --- shadow/3369.tmp.8603 Sat Sep 1 09:53:01 2001 *************** *** 0 **** --- 1,101 ---- + +============================================================================+ + | Sax2 parser crashes in the middle of a parse. Works once, fails, once, fai | + +----------------------------------------------------------------------------+ + | Bug #: 3369 Product: Xerces-C++ | + | Status: NEW Version: 1.5.1 | + | Resolution: Platform: PC | + | Severity: Critical OS/Version: Windows NT/2K | + | Priority: Other Component: SAX/SAX2 | + +----------------------------------------------------------------------------+ + | Assigned To: [EMAIL PROTECTED] | + | Reported By: [EMAIL PROTECTED] | + | CC list: Cc: | + +----------------------------------------------------------------------------+ + | URL: http://localhost/NotOnTheWebYet/RunInAnIsapiDll | + +============================================================================+ + | DESCRIPTION | + Using Borland Builder 5.0 with latest patches. I used the BCB4 project which + Builder upgrades to version 5. The project has a typedef of XMLCh which is of + type unsigned short in the file src/util/compilers/BorlandCDefs.hpp. Borland + C++ does not do implicit conversions of unsigned short to wchar_t, MS uses a + typedef unsigned short wchar_t and in borland wchar_t is a key word, so I had + to update the files that interface to the standard wide char library. All I + did was an explicit cast where appropriate(they are both two byte values). I + also had to add files that were missing from the project. I found this out by + compiling, checking the error, and then finding the correct files to include in + my build. + + Now that I have said that. I have the code working, but only part of the + time. I am using it inside of an ISAPI application with IIS5.0 on win2k. It + will be used on win9x as well with Personal Web Server. We are thinking about + migrating to Apache Web Server however since PWS is not supported on ME. + + I am sending an XML file up to a web server with a java applet, and this + works fine. The file is being stored properly and I can see where it is being + stored. I open the xml file and all is well. Plus, I am not getting any + exceptions thrown from the SAX2XMLReader when it parses. I am getting memory + access errors which are crashing out my program on runs. During debug the + exiting or erratic condition is taking place from within the call to + <SAX2XMLReader>.parse(pathtomyfile). I know this because I have set break + points everywhere, and the error is happening outside of anything visible to + me, even from outside of the DefaultHandler methods. Eventually I will build + the Xerces lib with code into my ISAPI, but at the moment I don't have time. I + can live with the pattern for a little while. + + There is one more thing I should add here before continuing to explain. + Before I added a substantial amount of actual code to my DefaultHandler sub + class my problem was different. The problem was tracked to the static method + XMLReaderFactor::createXMLReader(). I did not get far enough to be more + specific other than inside of createXMLReader a new instance of + SAX2XMLReaderImpl is being created. Inside of the constructor an instance of + XMLScanner(0) is being created. Inside of this the branching leads to a few + more static methods. I'm sorry for not having time to go further with that, + but there are for more places that could also be causing a problem, but I doubt + it. + + Inside of the constructor an array of XMLDocumentHandler*'s is being + created with new; then directly following this is a call to memset which sets + everthing to null without a check on the array value returned from the call to + new. Again, I doubt this is causing the issue, mainly because I have other + calls to new that are working fine, plus I get the same results on multiple + computers. + + There are three more creations of arrays using new at the bottom of the + method. These are in order... + //pasted from the source file SAX2XMLReaderImpl.cpp + fPrefixes = new RefStackOf<XMLBuffer> (10, false) ; + tempAttrVec = new RefVectorOf<XMLAttr> (10, false) ; + prefixCounts = new ValueStackOf<unsigned int>(10) ; + I only looked at this briefly as well. + + So, to make a long story short, the call to + XMLReaderFactory::createXMLReader() is causing a memory access error, but only + part of the time. It seems to go like this. Two calls would complete and two + would fail. This pattern continued until I added substantial code to my + DefaultHandler sub class. The pattern stopped after the addition of extra code + to the methods of the DefaultHandler sub class because the ISAPI module is + having these faults and having to be reloaded or taken out of and back into + memory by IIS which is reinitializing everthing as a new process. Thus starting + everything over again. + + This all leads me back to the substantial code in my DefaultHandler. This + part I don't understand. The bomb out is happening aside from this extra code, + so the addition of the code inside of the handler methods should not have an + affect, so I am at a loss. Since, I have not built the Xerces lib into the + ISAPI I can not debug them both in sync as I should. I will do this after I + get everthing working, but I wanted to let somebody know what I was + experiencing; maybe together we can figure out what the issue is. + + If you as the engineer working on this issue could please send me your + email address I will package everthing up(Xerces lib, ISAPI code, my java + program which you will need for the ISAPI to be able to read the input since I + am not fully using the http upload mechanism, and any files needed at run + time). Any help is truely appreciated. I thank you for your time. + + Wade Chandler + Lead Programmer + Metro IT Solutions + http://www.metrotriad.com/wchan + http://www.metrois.com + [EMAIL PROTECTED] + 336-725-1621 Ext. 1015 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
