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/01 18:53:01 UTC

[DO NOT REPLY: Bug 3369] New: Sax2 parser crashes in the middle of a parse. Works once, fails, once, fails, definite pattern.

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: xerces-c-dev@xml.apache.org                                  |
+ |  Reported By: wade.chandler@metrois.com                                    |
+ |      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
+ wade.chandler@metrois.com
+ 336-725-1621 Ext. 1015

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org