ID: 37083
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: SOAP related
Operating System: *
PHP Version: 5CVS-2006-04-14 (snap)
Assigned To: andrei
New Comment:
Andrei, also take a look at these lines in php_encoding.c:
line 358
if (encode == NULL) {
encode = get_conversion(UNKNOWN_TYPE);
}
if (encode->to_xml_before) {
data = encode->to_xml_before(&encode->details, data);
}
line 365
The get_conversion() may return NULL, but you're using encode without
checking it for NULL.
>From what I can see, the backtrace points exactly to this problem:
Program received signal SIGSEGV, Segmentation fault.
master_to_xml (encode=0x424b60, data=0x43fc28, style=1,
parent=0x429740)
at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:363
363 data =
encode->to_xml_before(&encode->details, data);
Previous Comments:
------------------------------------------------------------------------
[2006-04-15 16:40:42] [EMAIL PROTECTED]
>From the webserver log i can see that the crash occurs always in
function "get_conversion()" (SIGSEGV or SIGBUS):
CORE3262: Crash occurred in function get_conversion from module
/pangaea/webserver61/bin/libphp5.so
Funny is the follwing:
CORE3262: Crash occurred in function free from module
/usr/lib/libmtmalloc.so.1
When server dies with SIGILL (which is mostly the case)nothing is said
about the location.
------------------------------------------------------------------------
[2006-04-15 16:15:29] [EMAIL PROTECTED]
It is the same problem as before. The backtrace of the weserver is
unusable because stack corrupt (mostly SIGILL, sometimes SIGSEGV but
also without stack). I yesterday tried to get a backtrace (for the
problem you fixed) the whole afternoon... It was horrible. With the CLI
script it was reproducible but this time the CLI script works.
It is always soap client code, the soap server runs in AXIS (see wsdl
in client code script). The script is used in the webserver with some
additional parameter parsing logic, but the core used is the soap code
from my last mail.
I think the script does in CLI mode also bad things but it does not
crash. In the webserver, where more things are running at the same time
the corrupt memory leads to a crash.
I hoped that you see the error when looking at the WSDL used:
http://opteron.bremen.wdc-mare.org:8800/servlet/AXIS/Search?wsdl
Could be that there is an error in your code that makes this crash (the
xsd:anyType in the RangeQuery or in the result???)
------------------------------------------------------------------------
[2006-04-15 16:03:45] [EMAIL PROTECTED]
Does it crash in the client code or the server code? Can you provide a
short script that reproduces it on the webserver as well as a
backtrace?
------------------------------------------------------------------------
[2006-04-15 11:59:30] [EMAIL PROTECTED]
The bug is not fixed completely. With another webservice it crashes
(one with an xsd:anyType value in one of the complex types):
[15/Apr/2006:13:55:20] catastrophe (24983): CORE3260: Server crash
detected (signal SIGSEGV) [15/Apr/2006:13:55:20] info (24983):
CORE3261: Crash occurred in NSAPI SAF php5_execute
[15/Apr/2006:13:55:20] info (24983): CORE3262: Crash occurred in
function get_conversion from module
/pangaea/webserver61/bin/libphp5.so
Code:
<?php
for ($i=0; $i<20; $i++) {
echo "Loop: ".$i."\n";
$ws=new
SoapClient('http://opteron.bremen.wdc-mare.org:8800/servlet/AXIS/Search?wsdl',array('encoding'=>'ISO-8859-1'
$search=new stdClass();
$search->queryString='argo';
$search->ranges[]=$r=new stdClass();
$r->field='maxDateTime';
$r->min='2003-04-01';
$search->index='all';
$res=$ws->search($search,$i*10,10);
}
?>
The problem is that this cannot be reproduced with CLI, this crashes
with SIGSEGV or SIGILL in the webserver only, so the above CLI script
works.
------------------------------------------------------------------------
[2006-04-15 11:39:27] [EMAIL PROTECTED]
Works as CLI in patched snapshot:
[EMAIL PROTECTED]:~/install/php5.1-200604151030/sapi/cli$ ./php
~/test/test.php
Loop: 0
Loop: 1
Loop: 2
Loop: 3
Loop: 4
Loop: 5
Loop: 6
Loop: 7
Loop: 8
Loop: 9
Loop: 10
Loop: 11
Loop: 12
Loop: 13
Loop: 14
Loop: 15
Loop: 16
Loop: 17
Loop: 18
Loop: 19
...and in the webserver with WSDL caching enabled:
http://www.pangaea.de/PangaVista?query=grobe
You can apply this patch and close this bug.
I have only the following question:
Is it correct that no more /tmp/wsdl-* files are generated? There
should be some hint in php.ini, that the wsdl_cache_dir is not longer
needed. Or WHEN will it be used now (if not ZTS,...)?
Thanks for this patch, it is now really faster in this multithreaded
webserver where no longer the wsdl/wsdl-cache file needs to be
evaluated!
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/37083
--
Edit this bug report at http://bugs.php.net/?id=37083&edit=1
