|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #56488 SDO_DAS_XML::create() core dumps
Submitted: 2005-08-11 13:27 UTC Modified: 2006-10-30 06:24 UTC
From: Assigned: mfp (profile)
Status: Closed Package: SCA_SDO (PECL)
PHP Version: 5_1 CVS-2005-08-11 (dev) OS: FreeBSD 5.3-RELEASE
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
New email:
PHP Version: OS:


 [2005-08-11 13:27 UTC]
SDO_DAS:XML::create() causes segmentation fault.

PHP6-dev was configured with:
./configure --with-zend-vm=GOTO --enable-debug --with-apxs2=/usr/local/sbin/apxs --prefix=/usr/home/dev

SDO was configured with:
./configure --prefix=/usr/home/dev/ --with-php-config=/usr/home/dev/bin/php-config

php.ini (php.ini-recommended plus these two lines):

Reproduce code:
try {
    $xmldas = SDO_DAS_XML::create("atom.xsd");
} catch (SDO_TypeNotFoundException $e) {
    print("Type is not defined in the xsd file");
} catch (SDO_DAS_XML_ParserException $e) {
    print("Problem while parsing");

Actual result:
(gdb) bt
#0  0x772f2f3a in ?? ()
#1  0x28397a4f in xmlCharEncInFunc () from /usr/local/lib/
#2  0x283bde0a in xmlParserInputBufferGrow () from /usr/local/lib/
#3  0x28399b81 in xmlParserInputGrow () from /usr/local/lib/
#4  0x2839d498 in xmlGROW () from /usr/local/lib/
#5  0x283a8de2 in xmlParseStartTag2 () from /usr/local/lib/
#6  0x283a9dfc in xmlParseElement () from /usr/local/lib/
#7  0x283a9c5a in xmlParseContent () from /usr/local/lib/
#8  0x283aa089 in xmlParseElement () from /usr/local/lib/
#9  0x283a9c5a in xmlParseContent () from /usr/local/lib/
#10 0x283aa089 in xmlParseElement () from /usr/local/lib/
#11 0x283a9c5a in xmlParseContent () from /usr/local/lib/
#12 0x283aa089 in xmlParseElement () from /usr/local/lib/
#13 0x283a9c5a in xmlParseContent () from /usr/local/lib/
#14 0x283aa089 in xmlParseElement () from /usr/local/lib/
#15 0x283ab4d7 in xmlParseDocument () from /usr/local/lib/
#16 0x283af749 in xmlSAXUserParseFile () from /usr/local/lib/
#17 0x2871f324 in commonj::sdo::xmldas::SAX2Parser::parse () from /usr/home/dev/lib/php/extensions/debug-non-zts-20050809/
#18 0x28741062 in commonj::sdo::xmldas::XSDHelperImpl::defineFile () from /usr/home/dev/lib/php/extensions/debug-non-zts-20050809/
#19 0x2873be76 in commonj::sdo::xmldas::XMLDASImpl::loadSchemaFile () from /usr/home/dev/lib/php/extensions/debug-non-zts-20050809/
#20 0x2873ba44 in commonj::sdo::xmldas::XMLDASImpl::XMLDASImpl () from /usr/home/dev/lib/php/extensions/debug-non-zts-20050809/
#21 0x2873b29e in commonj::sdo::xmldas::XMLDAS::create () from /usr/home/dev/lib/php/extensions/debug-non-zts-20050809/
#22 0x28849b33 in zif_SDO_DAS_XML_create () from /usr/home/dev/lib/php/extensions/debug-non-zts-20050809/
#23 0x0826de9f in zend_do_fcall_common_helper_SPEC (execute_data=0xbfbfd4e0) at zend_vm_execute.h:184
#24 0x0826e875 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbfbfd4e0) at zend_vm_execute.h:305
#25 0x0826db79 in execute (op_array=0x8470f24) at zend_vm_execute.h:87
#26 0x0824709c in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/home/dev/php-src/Zend/zend.c:1078
#27 0x082052c2 in php_execute_script (primary_file=0xbfbfec30) at /usr/home/dev/php-src/main/main.c:1672
#28 0x082b35d8 in main (argc=2, argv=0xbfbfecc0) at /usr/home/dev/php-src/sapi/cli/php_cli.c:1039


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2005-08-11 13:38 UTC]
that atom.xsd file can be found at if that helps.
 [2005-08-12 08:47 UTC] matthew_peters at uk dot ibm dot com
Thanks for raising the defect. Just to let you know: we are working on it. There's two problems - 1. there's something in the xsd that causes us a problem 2. the exception that is thrown is not getting through to where it should so we just get Aborted instead of printing out the exception message. We are looking independently at both problems.

The stack trace and xsd file were helpful. We'll be in touch.
 [2005-08-12 11:46 UTC] matthew_peters at uk dot ibm dot com
Just checked in new versions of SDOSAX2Parser.* - they change the behaviour so you get a message saying parse problem, but then just termination. The exception still is not getting through. Still working on it.
 [2005-08-13 06:38 UTC] matthew_peters at uk dot ibm dot com
Apologies, my test case was wrong and so my last message was wrong. With the SDOSAX2Parser.* files checked in yesterday you do now get the exception thrown with useful text. 

We find with the atom.xsd that the exception message mentions a problem with contentType (I think, from memory). We examine the xsd file because we need to construct our own internal model in terms of SDO types and properties. The reason this causes us problems is that it is a type that is based on a string but also has properties. This is not something we have tried to model so far. We have gone back to the architect to see exactly how this should be expressed in the SDO model... We'll be in touch.
 [2005-08-16 13:26 UTC] matthew_peters at uk dot ibm dot com
We're still waiting on an answer from the architect regarding how we should model "contentType". To confirm, at the moment we take the restriction with base="xs:string" as a trigger to define it as based on an SDO string, and then the extra content catches us out.

BTW, we read through the xsd and see another problem that will surface if we fix the first. The xs:any, also in contentType, is going to cause us a problem. We need to model that as a so-called SDO 'open' type, which is a type that can handle XML mixed content and have extra properties added dynamically. Although the java version of SDO has support for open types we haven't added it yet to the PHP version. I don't expect that we will get to it for some months, though. Sorry.

In case you're interested, the rules that we have to follow when mapping XSD schema -> SDO model are in the SDO 2 spec which is pointed to by
and the particular rule is the bottom cell of the table on p. 75. That's probably more information than you ever wanted :-)
 [2005-08-24 08:45 UTC] matthew_peters at uk dot ibm dot com
Well, there are two aspects to this.

The first is the fact that it used to give a segmentation fault, which I think we have fixed. For that reason I propose to close this bug as fixed, if you agree. That leaves the fact that we do not handle the atom.xsd that you supplied.

On that second point, which I am happy to accept as a new bug or feature request if you like, we have had some different opinions.

One opinion is that there is a problem with the XSD. We get this error from the xml parser on the original XSD at
[Error] atom.xsd:147:38: src-ct.1: Complex Type Definition Representation Error for type 'contentType'.  When complexContent is used, the base type must be a complexType.

We don't see that error when we try to parse the xsd to produce the SDO model, because we use libxml2, which does not pick this up.

We understand from Sam Ruby that the official schema for Atom is expressed in RelaxNG:
and we have no RelaxNG parser.

Sam also told us that there are conversion tools, but people have had varying results with them:

All in all, I don't see us being able to use this exact xsd without problems for a while to come.

Let us know what you would like to do with this bug report.
 [2005-08-28 15:38 UTC]
Seems to core dump when I change the charset
(See - at least on windows. Have *no* idea have to generate backtrace on windows, will try to make some further tests before we close this.
 [2005-08-28 15:58 UTC]
Got a friend to generate backtrace on linux, see
Got no idea where these warnings come from, could be his setup (either way, another matter).

Haven't had much time to dig deeper into this matter, and probably won't have until next weekend.
 [2005-09-07 13:26 UTC]
This bug-report was orginally written cause of segmentation fault when exception didn't get through to user, which is fixed, thanks (closing report).

The latter (charset) is another bug, mistakenly reported here (seems to be dupe of #5297, which is marked as fixed).

contentType/complexType issue is not directly related to SDO, afaict, so should be disregarded untill someone belives otherwise and submits feature/change request :)
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Nov 27 03:03:12 2021 UTC