[
https://issues.apache.org/jira/browse/XERCESC-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Ivarsson updated XERCESC-1920:
---------------------------------------
Description:
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
was:
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 havent tried it with any of the DOMParsers, but I would guess that the
behaviour would be similar if the same underlaying mechanisms is (re)used
> 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
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
