php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #37083 Frequent crashs in SOAP extension with new WSDL caching code in multithread WS
Submitted: 2006-04-14 13:23 UTC Modified: 2006-04-18 13:08 UTC
From: thetaphi@php.net Assigned: andrei (profile)
Status: Closed Package: SOAP related
PHP Version: 5CVS-2006-04-14 (snap) OS: *
Private report: No CVE-ID: None
 [2006-04-14 13:23 UTC] thetaphi@php.net
Description:
------------
Yesterday I tried the newest PHP 5.1 snapshot on my SunONE webserver (I am the maintainer of the NSAPI SAPI code). This webserver is multithreaded so your new WSDL caching code in ext/soap should work great. But it doesn't.

The first call to a php script that uses SoapClient works correct (everytime). Further requests to the same script crash the webserver with SIGSERV, SIGBUS, SIGILL (illegal instruction!!!).

Because of the SIGILL I suspect that the caching code overwrites some executale code.

The problem is that it happens at totally different locations, most times there is not even a core dump available that can be analyzed (stack is corrupt so no dump availabe). When I disable soap.wsdl-cache completely, everything works again without any crash. I have seen that with the new code no longer /tmp/wsdl-XXXXX files are generated. Is there a possibility to switch 
to the older file-based caching code? For eaxample as enumeration in the wsdl-cache php.ini configuration option? Is there any other possibility to disable the wsdl cache code without undoing a lot of soap patches? I want to update the webserver because of security 
reasons to latest snapshot.

Do you have similar problems with other webservers that are multithreaded? Sorry that I cannot give more helpful information (the crashes are totally different and the corefiles are mostly useless).

Reproduce code:
---------------
The first time after restart this code works without problems. Later calls (when using the cashed WSDL) mostly crash:
$ws=new SoapClient('http://ws.pangaea.de/ws/services/PangaVista?wsdl',array('encoding'=>'ISO-8859-1'));
$ua=isset($_SERVER['HTTP_USER_AGENT'])?$_SERVER['HTTP_USER_AGENT']:'nobrowser/0.0';
$sess=$ws->registerSession($this->session,$ua,$_SERVER['REMOTE_HOST'],"PangaVista");
$search=new stdClass();
$search->queryString='grobe';
$res=$ws->advSearch($sess,$search,$this->offset,$this->count,'thumb');
print_r($res);


Expected result:
----------------
No crash :)

Actual result:
--------------
All crashs from server log:

[13/Apr/2006:16:47:26] catastrophe (23690): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:16:47:26] info (23690): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:16:47:43] catastrophe (25142): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:16:47:43] info (25142): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:16:48:33] catastrophe (25149): CORE3260: Server crash detected (signal SIGILL) 
[13/Apr/2006:16:48:33] info (25149): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:16:49:35] catastrophe (25237): CORE3260: Server crash detected (signal SIGILL) 
[13/Apr/2006:16:49:35] info (25237): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:18:38:15] catastrophe ( 8381): CORE3260: Server crash detected (signal SIGBUS) 
[13/Apr/2006:18:38:15] info ( 8381): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:18:38:15] info ( 8381): CORE3262: Crash occurred in function master_to_xml from module /pangaea/webserver61/bin/libphp5.so 
[13/Apr/2006:18:39:13] catastrophe (10615): CORE3260: Server crash detected (signal SIGBUS) 
[13/Apr/2006:18:39:13] info (10615): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:18:39:13] info (10615): CORE3262: Crash occurred in function master_to_xml from module /pangaea/webserver61/bin/libphp5.so 
[13/Apr/2006:18:39:43] catastrophe (11680): CORE3260: Server crash detected (signal SIGILL) 
[13/Apr/2006:18:39:43] info (11680): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:18:44:03] catastrophe (11702): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:18:44:03] info (11702): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:18:44:03] info (11702): CORE3262: Crash occurred in function encode_reset_ns from module /pangaea/webserver61/bin/libphp5.so 
[13/Apr/2006:18:45:48] catastrophe (11763): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:18:45:48] info (11763): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:18:45:59] catastrophe (11823): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:18:45:59] info (11823): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:18:59:50] catastrophe (12139): CORE3260: Server crash detected (signal SIGILL) 
[13/Apr/2006:18:59:50] info (12139): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:19:00:26] catastrophe (12148): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:19:00:26] info (12148): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:19:02:17] catastrophe (12182): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:19:02:17] info (12182): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:19:02:17] info (12182): CORE3262: Crash occurred in function strcmp from module /usr/lib/libc.so.1 
[13/Apr/2006:19:02:29] catastrophe (12214): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:19:02:29] info (12214): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:19:12:54] catastrophe (23547): CORE3260: Server crash detected (signal SIGILL) 
[13/Apr/2006:19:12:54] info (23547): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:20:02:13] catastrophe ( 1965): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:20:02:13] info ( 1965): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:20:02:13] info ( 1965): CORE3262: Crash occurred in function encode_reset_ns from module /pangaea/webserver61/bin/libphp5.so 
[13/Apr/2006:20:04:37] catastrophe ( 3221): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:20:04:37] info ( 3221): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:20:04:37] info ( 3221): CORE3262: Crash occurred in function whiteSpace_collapse from module /pangaea/webserver61/bin/libphp5.so 
[13/Apr/2006:20:05:53] catastrophe ( 5772): CORE3260: Server crash detected (signal SIGILL) 
[13/Apr/2006:20:05:53] info ( 5772): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:20:07:38] catastrophe ( 5845): CORE3260: Server crash detected (signal SIGBUS) 
[13/Apr/2006:20:07:38] info ( 5845): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:20:07:38] info ( 5845): CORE3262: Crash occurred in function master_to_xml from module /pangaea/webserver61/bin/libphp5.so 
[13/Apr/2006:20:13:10] catastrophe ( 5916): CORE3260: Server crash detected (signal SIGSEGV) 
[13/Apr/2006:20:13:10] info ( 5916): CORE3261: Crash occurred in NSAPI SAF php5_execute 
[13/Apr/2006:20:13:10] info ( 5916): CORE3262: Crash occurred in function whiteSpace_collapse from module /pangaea/webserver61/bin/libphp5.so 


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-04-14 14:29 UTC] tony2001@php.net
Did you try to run the same code using CLI ?
 [2006-04-14 14:32 UTC] thetaphi@php.net
With CLI it works because CLI does not use the WSDL cache in memory (after finishing the program it forgets its cache). The first call to the webservice always works, even in the webserver.
 [2006-04-14 14:57 UTC] thetaphi@php.net
But your idea was good. I tried it with a CLI script that calls the same code in a for loop:

pangaeaw@pans1:~/test$ php test.php 
Loop: 0
Loop: 1
Illegal Instruction (core dumped)

Now i debug this...

(gdb) run test.php
Starting program: /pangaea/gnu/bin/php test.php
Loop: 0
Loop: 1

Program received signal SIGILL, Illegal instruction.
0x0071727c in ?? ()
(gdb) bt
#0  0x0071727c in ?? ()
#1  0x00717280 in ?? ()
Previous frame identical to this frame (corrupt stack?)
(gdb)

Compiling with/without --enable-debug does not show more info. But the error is always SIGILL.

The code used for testing:
pangaeaw@pans1:~/test$ cat test.php
<?php
for ($i=0; $i<20; $i++) {
 echo "Loop: ".$i."\n";
 $ws=new SoapClient('http://ws.pangaea.de/ws/services/PangaVista?wsdl',array('encoding'=>'ISO-8859-1'));
 $ua='test/1.0';
 $sess=$ws->registerSession(NULL,$ua,'127.0.0.1',"PangaVista");
 $search=new stdClass();
 $search->queryString='grobe';
 $res=$ws->advSearch($sess,$search,0,10,'thumb');
}
?>
 [2006-04-14 15:06 UTC] derick@php.net
Can definitely reproduce this. Valgrind trace follows:

==8798== Invalid read of size 4
==8798==    at 0x81FE864: master_to_xml (php_encoding.c:362)
==8798==    by 0x8201ED5: model_to_xml_object (php_encoding.c:1459)
==8798==    by 0x82022B9: model_to_xml_object (php_encoding.c:1540)
==8798==    by 0x8202A93: to_xml_object (php_encoding.c:1716)
==8798==    by 0x8208C9C: sdl_guess_convert_xml (php_encoding.c:2979)
==8798==    by 0x81FE8AF: master_to_xml (php_encoding.c:366)
==8798==    by 0x81F9732: serialize_zval (soap.c:4162)
==8798==    by 0x81F9633: serialize_parameter (soap.c:4135)
==8798==    by 0x81F8AA5: serialize_function_call (soap.c:3970)
==8798==    by 0x81F2545: do_soap_call (soap.c:2477)
==8798==    by 0x81F3A76: zif_SoapClient___call (soap.c:2691)
==8798==    by 0x837BE3F: zend_call_function (zend_execute_API.c:952)
==8798==  Address 0x4B165E4 is 36 bytes inside a block of size 44 free'd
==8798==    at 0x401D048: free (vg_replace_malloc.c:235)
==8798==    by 0x820AA2D: delete_encoder (php_encoding.c:3301)
==8798==    by 0x83912EB: zend_hash_destroy (zend_hash.c:521)
==8798==    by 0x8235248: delete_sdl_impl (php_sdl.c:3196)
==8798==    by 0x82350C7: get_sdl (php_sdl.c:3153)
==8798==    by 0x81F1A76: zif_SoapClient_SoapClient (soap.c:2301)
==8798==    by 0x83A6870: execute_internal (zend_execute.c:1368)
==8798==    by 0x4A1D670: xdebug_execute_internal (xdebug.c:1428)
==8798==    by 0x83A6EB1: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:202)
==8798==    by 0x83A7B59: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322)
==8798==    by 0x83A6A44: execute (zend_vm_execute.h:92)
==8798==    by 0x4A1D30C: xdebug_execute (xdebug.c:1366)
==8798==
==8798== Invalid read of size 4
==8798==    at 0x81FE886: master_to_xml (php_encoding.c:365)
==8798==    by 0x8201ED5: model_to_xml_object (php_encoding.c:1459)
==8798==    by 0x82022B9: model_to_xml_object (php_encoding.c:1540)
==8798==    by 0x8202A93: to_xml_object (php_encoding.c:1716)
==8798==    by 0x8208C9C: sdl_guess_convert_xml (php_encoding.c:2979)
==8798==    by 0x81FE8AF: master_to_xml (php_encoding.c:366)
==8798==    by 0x81F9732: serialize_zval (soap.c:4162)
==8798==    by 0x81F9633: serialize_parameter (soap.c:4135)
==8798==    by 0x81F8AA5: serialize_function_call (soap.c:3970)
==8798==    by 0x81F2545: do_soap_call (soap.c:2477)
==8798==    by 0x81F3A76: zif_SoapClient___call (soap.c:2691)
==8798==    by 0x837BE3F: zend_call_function (zend_execute_API.c:952)
==8798==  Address 0x4B165D8 is 24 bytes inside a block of size 44 free'd
==8798==    at 0x401D048: free (vg_replace_malloc.c:235)
==8798==    by 0x820AA2D: delete_encoder (php_encoding.c:3301)
==8798==    by 0x83912EB: zend_hash_destroy (zend_hash.c:521)
==8798==    by 0x8235248: delete_sdl_impl (php_sdl.c:3196)
==8798==    by 0x82350C7: get_sdl (php_sdl.c:3153)
==8798==    by 0x81F1A76: zif_SoapClient_SoapClient (soap.c:2301)
==8798==    by 0x83A6870: execute_internal (zend_execute.c:1368)
==8798==    by 0x4A1D670: xdebug_execute_internal (xdebug.c:1428)
==8798==    by 0x83A6EB1: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:202)
==8798==    by 0x83A7B59: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (zend_vm_execute.h:322)
==8798==    by 0x83A6A44: execute (zend_vm_execute.h:92)
==8798==    by 0x4A1D30C: xdebug_execute (xdebug.c:1366)
==8798==

gdb backtrace:
#0  0x00000030 in ?? ()
#1  0x081fe8d9 in master_to_xml (encode=0x873eca0, data=0x8733218, style=1,
    parent=0x873dcd8) at /dat/dev/php/php-5.1dev/ext/soap/php_encoding.c:369
#2  0x08201ed6 in model_to_xml_object (node=0x873dcd8, model=0x874a7e0,
    object=0x87331b8, style=1, strict=1)
    at /dat/dev/php/php-5.1dev/ext/soap/php_encoding.c:1459
#3  0x082022ba in model_to_xml_object (node=0x873dcd8, model=0x874b228,
    object=0x87331b8, style=1, strict=1)
    at /dat/dev/php/php-5.1dev/ext/soap/php_encoding.c:1540
#4  0x08202a94 in to_xml_object (type=0x874bf20, data=0x87331b8, style=1,
    parent=0x873dd50) at /dat/dev/php/php-5.1dev/ext/soap/php_encoding.c:1716
#5  0x08208c9d in sdl_guess_convert_xml (enc=0x874bf20, data=0x87331b8,
    style=1, parent=0x873dd50)
    at /dat/dev/php/php-5.1dev/ext/soap/php_encoding.c:2979
#6  0x081fe8b0 in master_to_xml (encode=0x874bf20, data=0x87331b8, style=1,
    parent=0x873dd50) at /dat/dev/php/php-5.1dev/ext/soap/php_encoding.c:366
#7  0x081f9733 in serialize_zval (val=0x87331b8, param=0x874bad0,
    paramName=0x874afb0 "searchDescription", style=1, parent=0x873dd50)
    at /dat/dev/php/php-5.1dev/ext/soap/soap.c:4162
#8  0x081f9634 in serialize_parameter (param=0x874bad0, param_val=0x87331b8,
    index=1, name=0x0, style=1, parent=0x873dd50)
    at /dat/dev/php/php-5.1dev/ext/soap/soap.c:4135
#9  0x081f8aa6 in serialize_function_call (this_ptr=0x87330b0,
    function=0x874bc80, function_name=0x0,
    uri=0x874bca8 "urn:PanWebServices.PangaVista", arguments=0x874e490,
    arg_count=5, version=1, soap_headers=0x0)
    at /dat/dev/php/php-5.1dev/ext/soap/soap.c:3970
#10 0x081f2546 in do_soap_call (this_ptr=0x87330b0,
    function=0x8739fd8 "advSearch", function_len=9, arg_count=5,
    real_args=0x874e490, return_value=0x87395a8,
    location=0x874ced8 "http://ws.pangaea.de/ws/services/PangaVista",
    soap_action=0x0, call_uri=0x0, soap_headers=0x0, output_headers=0x0)
    at /dat/dev/php/php-5.1dev/ext/soap/soap.c:2477
#11 0x081f3a77 in zif_SoapClient___call (ht=2, return_value=0x87395a8,
    return_value_ptr=0x0, this_ptr=0x87330b0, return_value_used=1)
    at /dat/dev/php/php-5.1dev/ext/soap/soap.c:2691
#12 0x0837be40 in zend_call_function (fci=0xbf8fb374, fci_cache=0xbf8fb348)
    at /dat/dev/php/php-5.1dev/Zend/zend_execute_API.c:952
#13 0x0839b6ab in zend_call_method (object_pp=0xbf8fb42c, obj_ce=0x8703ea0,
    fn_proxy=0x8703fbc, function_name=0x85a6318 "__call", function_name_len=6,
    retval_ptr_ptr=0xbf8fb3ec, param_count=2, arg1=0x8739810, arg2=0x87398e8)
    at /dat/dev/php/php-5.1dev/Zend/zend_interfaces.c:88
#14 0x083a3008 in zend_std_call_user_call (ht=5, return_value=0x8739928,
    return_value_ptr=0x0, this_ptr=0x87330b0, return_value_used=1)
    at /dat/dev/php/php-5.1dev/Zend/zend_object_handlers.c:634
#15 0x083a6871 in execute_internal (execute_data_ptr=0xbf8fb774,
    return_value_used=1) at /dat/dev/php/php-5.1dev/Zend/zend_execute.c:1368
#16 0xb76d0671 in xdebug_execute_internal (current_execute_data=0xbf8fb774,
    return_value_used=1) at /dat/dev/php/xdebug/xdebug.c:1428
#17 0x083a6eb2 in zend_do_fcall_common_helper_SPEC (execute_data=0xbf8fb774)
    at zend_vm_execute.h:202
#18 0x083a7b5a in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0xbf8fb774)
    at zend_vm_execute.h:322
#19 0x083a6a45 in execute (op_array=0x8732908) at zend_vm_execute.h:92
#20 0xb76d030d in xdebug_execute (op_array=0x8732908)
    at /dat/dev/php/xdebug/xdebug.c:1366
#21 0x08387aed in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /dat/dev/php/php-5.1dev/Zend/zend.c:1109
#22 0x0833fdca in php_execute_script (primary_file=0xbf8fdc10)
    at /dat/dev/php/php-5.1dev/main/main.c:1728
#23 0x083f7b74 in main (argc=2, argv=0xbf8fdd24)
    at /dat/dev/php/php-5.1dev/sapi/cli/php_cli.c:1092

 [2006-04-14 15:12 UTC] thetaphi@php.net
I have now compiled it again only with xml and soap modules linked statically with --enable-debug, this time it coredumps even in the first loop (there must be something completely broken, that the script generates two different signals with/without debug). From the webserver logs you see that master_to_xml is also in the error log (together with other soap functions):

(gdb) run ~/test/test.php
Starting program: /pangaea/install/php5.1-200604131430/sapi/cli/php ~/test/test.php
Loop: 0

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);
(gdb) bt
#0  master_to_xml (encode=0x424b60, data=0x43fc28, style=1, parent=0x429740)
    at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:363
#1  0x0011ca0c in model_to_xml_object (node=0x429740, model=0x43a8b0, object=0x43fc28, style=1, strict=1)
    at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1461
#2  0x0011cb5c in model_to_xml_object (node=0x429740, model=0x43a8e0, object=0x428258, style=1, strict=1)
    at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1542
#3  0x0011d300 in to_xml_object (type=0x439ef8, data=0x428258, style=1, parent=0x423138)
    at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:1718
#4  0x0011fd60 in sdl_guess_convert_xml (enc=0x439ef8, data=0x428258, style=1, parent=0x423138)
    at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:2981
#5  0x0011b7e4 in master_to_xml (encode=0x439ef8, data=0x428258, style=1, parent=0x423138)
    at /pangaea/install/php5.1-200604131430/ext/soap/php_encoding.c:366
#6  0x0010d45c in serialize_zval (val=0x428258, param=0x42f430, paramName=0x413718 "searchDescription", style=1, 
    parent=0x423138) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:4167
#7  0x0010d60c in serialize_parameter (param=0x42f430, param_val=0x428258, index=1, name=0x0, style=1, 
    parent=0x423138) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:4140
#8  0x001124ac in serialize_function_call (this_ptr=0x427f60, function=0x415118, 
    function_name=0x1 <Address 0x1 out of bounds>, uri=0x42f430 "", arguments=0x44059c, arg_count=5, version=1, 
    soap_headers=0x0) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:3975
#9  0x001132ac in do_soap_call (this_ptr=0x427f60, function=0x440650 "advSearch", function_len=9, arg_count=5, 
    real_args=0x440598, return_value=0x43fda0, location=0x43a6f0 "http://ws.pangaea.de/ws/services/PangaVista", 
    soap_action=0x0, call_uri=0x0, soap_headers=0x0, output_headers=0x0)
    at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:2482
#10 0x00113ebc in zif_SoapClient___call (ht=2, return_value=0x43fda0, return_value_ptr=0x0, this_ptr=0x427f60, 
    return_value_used=1) at /pangaea/install/php5.1-200604131430/ext/soap/soap.c:2696
#11 0x002023bc in zend_call_function (fci=0xffbfef98, fci_cache=0x363c00)
    at /pangaea/install/php5.1-200604131430/Zend/zend_execute_API.c:952
#12 0x002226dc in zend_call_method (object_pp=0xffbff0b0, obj_ce=0x3d0e38, fn_proxy=0x3d0f54, 
    function_name=0x2ee3c8 "__call", function_name_len=6, retval_ptr_ptr=0xffbff04c, param_count=1515870810, 
    arg1=0x440008, arg2=0x4403a0) at /pangaea/install/php5.1-200604131430/Zend/zend_interfaces.c:88
#13 0x0022904c in zend_std_call_user_call (ht=-4198224, return_value=0x43ff60, return_value_ptr=0x0, 
    this_ptr=0x427f60, return_value_used=1) at /pangaea/install/php5.1-200604131430/Zend/zend_object_handlers.c:634
#14 0x0022e8fc in zend_do_fcall_common_helper_SPEC (execute_data=0xffbff388) at zend_vm_execute.h:200
#15 0x0022e0d0 in execute (op_array=0x422d08) at zend_vm_execute.h:92
#16 0x0020fef0 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /pangaea/install/php5.1-200604131430/Zend/zend.c:1109
#17 0x001cdb58 in php_execute_script (primary_file=0xffbffc28)
---Type <return> to continue, or q <return> to quit---
    at /pangaea/install/php5.1-200604131430/main/main.c:1732
#18 0x0029100c in main (argc=2, argv=0xffbffcc4) at /pangaea/install/php5.1-200604131430/sapi/cli/php_cli.c:1092
(gdb)
 [2006-04-15 06:16 UTC] andrei@php.net
Could you try the following patch and make sure it works for you?

http://www.php.net/~andrei/soap_bug.diff
 [2006-04-15 11:39 UTC] thetaphi@php.net
Works as CLI in patched snapshot:

pangaeaw@pans1:~/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!
 [2006-04-15 11:59 UTC] thetaphi@php.net
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 16:03 UTC] andrei@php.net
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 16:15 UTC] thetaphi@php.net
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:40 UTC] thetaphi@php.net
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 20:46 UTC] tony2001@php.net
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);
 [2006-04-15 21:50 UTC] thetaphi@php.net
And xsd:anyType is mapped to xml without encoding... Could this be the problem now?
 [2006-04-16 00:09 UTC] thetaphi@php.net
From the logs on the AXIS side of the server I can see that the crash now occurs on the decoding side (parsing the response from AXIS). Hope that helps...
 [2006-04-16 00:26 UTC] thetaphi@php.net
And when returning an empty Apache Map (see wsdl) in the AXIS code it does not crash anymore. With all that the problem seems to be the decoding of the Apache Map entries of type xsd:anyType values from the SOAP response to PHP datatypes.
 [2006-04-18 13:08 UTC] dmitry@php.net
Fixed in CVS HEAD and PHP_5_1.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 08:01:29 2024 UTC