[
https://issues.apache.org/jira/browse/XERCESC-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boris Kolpackov closed XERCESC-1920.
------------------------------------
Assignee: Boris Kolpackov
Fix Version/s: 3.1.1
3.2.0
Resolution: Fixed
Fix is in SVN and will be included in the upcoming 3.1.1 release. Thanks for
the report!
> UnixHTTPURLInputStream core-dumps
> ---------------------------------
>
> Key: XERCESC-1920
> URL: https://issues.apache.org/jira/browse/XERCESC-1920
> Project: Xerces-C++
> Issue Type: Bug
> Components: SAX/SAX2
> Affects Versions: 3.0.1
> Environment: Solaris 32 bit
> Reporter: Kristian Ivarsson
> Assignee: Boris Kolpackov
> Fix For: 3.1.1, 3.2.0
>
>
> Using SAX2XMLReader or SAXParser to parse following XML (note the tripple
> slashes) makes the application to core dump and a SEGV occurs in
> UnixHTTPURLInputStream::UnixHTTPURLInputStream() where function
> gethostbyname() is called
> ...
> const char * const xml =
> "<?xml version='1.0' encoding='ISO-8859-1' standalone='no'?>"
> "<!DOCTYPE root SYSTEM 'http:///server.org/dtd.dtd'>"
> "<root/>";
> ...
> What happens is that the first (and only) argument to gethostbyname() is 0
> (zero/null) and some inner machanism of gethostbyname() cannot handle that
> I'm not sure what class/mechanism in XercesC is to blame though ?
> It could be XMLURL::XMLURL() that doesn't throw because of an invalid URL
> It could be XMLURL::getHost() that returns 0 instead of an empty
> XMLCh-sequence
> It could be XMLString::transcode() that doesn't complain when transcoding a
> null-XMLCh-sequence
> It could be ArrayJanoitor::ArrayJanoitor() that doesn't complain about that
> an unnecessary assignment has ben given to it
> It could be UnixHTTPURLInputStream::UnixHTTPURLInputStream() that tries to
> operate on a null-char-array
> It could be Solaris::gethostbyname() that doesn't have proper error-handling
> of input parameters (cannot be solved in this project though)
> I haven't tried it with any of the DOMParsers, but I would guess that the
> behaviour would be similar if the same underlaying mechanisms are (re)used
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
