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 "Kristian Ivarsson (JIRA)" <xe...@xml.apache.org> on 2010/04/19 14:31:52 UTC
[jira] Created: (XERCESC-1920) UnixHTTPURLInputStream core-dumps
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 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
--
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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Updated: (XERCESC-1920) UnixHTTPURLInputStream core-dumps
Posted by "Kristian Ivarsson (JIRA)" <xe...@xml.apache.org>.
[ 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Closed: (XERCESC-1920) UnixHTTPURLInputStream core-dumps
Posted by "Boris Kolpackov (JIRA)" <xe...@xml.apache.org>.
[ 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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Updated: (XERCESC-1920) UnixHTTPURLInputStream core-dumps
Posted by "Kristian Ivarsson (JIRA)" <xe...@xml.apache.org>.
[ https://issues.apache.org/jira/browse/XERCESC-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Ivarsson updated XERCESC-1920:
---------------------------------------
Labels: segmentation_fault (was: )
> 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org