|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #44882 SOAP extension object decoding bug
Submitted: 2008-05-01 18:02 UTC Modified: 2008-11-27 14:50 UTC
Avg. Score:4.9 ± 0.3
Reproduced:14 of 14 (100.0%)
Same Version:9 (64.3%)
Same OS:13 (92.9%)
From: mike at silverorange dot com Assigned: dmitry (profile)
Status: Closed Package: SOAP related
PHP Version: 5.2.5 OS: *
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: mike at silverorange dot com
New email:
PHP Version: OS:


 [2008-05-01 18:02 UTC] mike at silverorange dot com
When decoding a SOAP response into zvals, the decoder sometimes gets confused decoding objects. We noticed this using the PayPal Express Checkout SOAP API.

For one request type, the returned XML was correct; however, the decoded PHP objects that were returned were incorrect. One value that should have been a string was a string reference and an object that should have been an object was as string.

Upon further investigation, we found other users had been experiencing this specific problem using PayPal's SOAP API with PHP since PHP 5.2.2.

After a bit of CVS research, it seems the bug was introduced in in soap_encoding.c to fix bug #37013.

The patch at works around the bug for our needs, but it does not fix the underlying problem and probably reintroduces #37013.

Reproduce code:
I can't provide a runnable test case unless you have PayPal developer API credentials. If so, you can run the unit tests in the package at:

The second test will fail if the bug is present and pass if the bug is fixed.

I've attached a var_dump of broken an working SOAP results to illustrate the broken 'PayerInfo' element parsing.

Expected result:
object(stdClass)#114 (6) {
  string(20) "2008-05-01T17:41:45Z"
  string(7) "Success"
  string(13) "9d6aa8c0309df"
  string(8) "1.000000"
  string(6) "548868"
  object(stdClass)#113 (2) {
    string(20) "EC-6AU15743MX2745842"
    object(stdClass)#112 (6) {
      string(0) ""
      string(0) ""
      string(10) "unverified"
      object(stdClass)#110 (5) {
        string(0) ""
        string(0) ""
        string(0) ""
        string(0) ""
        string(0) ""
      string(0) ""
      object(stdClass)#111 (9) {
        string(0) ""
        string(0) ""
        string(0) ""
        string(0) ""
        string(0) ""
        string(0) ""
        string(0) ""
        string(6) "PayPal"
        string(4) "None"

Actual result:
object(stdClass)#114 (6) {
  string(20) "2008-05-01T17:56:31Z"
  string(7) "Success"
  string(13) "233fdab3c0758"
  string(8) "1.000000"
  string(6) "548868"
  object(stdClass)#113 (2) {
    &string(20) "EC-8JA130819B922424F"
    string(20) "EC-8JA130819B922424F"


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-06-23 15:23 UTC] anomie at users dot sf dot net
Here is a test case that illustrates the bug, using the same technique the ext/soap test cases in the PHP distribution use. Please excuse the big block-o-base64, the namespace URIs in the XML were apparently triggering your spam filter.


class TestSoapClient extends SoapClient {
	public function __doRequest($req, $loc, $act, $ver, $oneway){
		return gzinflate(base64_decode($data));

$client=new TestSoapClient("");

 [2008-10-01 20:27 UTC] mike at silverorange dot com
I've moved the test provided by anomie into a phpt file at The WSDL file is not included locally as it is the copyrighted work of PayPal.

The test passes using the associated patch but fails against the latest snapshot (5.2-200810011830).

What else is needed to get this bug fixed?
 [2008-10-21 11:35 UTC]
Please try using this CVS snapshot:
For Windows:

 [2008-10-21 12:39 UTC] mike at silverorange dot com
The test still fails using the 5.2-200810211030 snapshot.
 [2008-11-07 16:12 UTC] anomie at users dot sf dot net
Still fails in php5.2-200811071330.tar.bz2.
 [2008-11-07 16:45 UTC] anomie at users dot sf dot net
I did a little digging for you PHP devs. What happens here is:

1. Something does a first pass through the soap xml response.
1a. For each node, a zval is allocated.
1b. soap_check_xml_ref saves the pointer to the allocated zval for each node.

2. Sometime after this, all those zvals from the first pass get freed.

3. Something does a second pass through the soap xml response.
3a. For each node, a zval is allocated. If we're lucky, the allocated zval is at the same address as during the first pass and nothing overwrote that memory in the mean time.
3b. soap_check_xml_ref tries to reuse the saved zval pointer for each node. If we got lucky in 3a, it seems to work fine. If we're unlucky, it now uses the wrong zval or something that's not a zval at all.
 [2008-11-17 14:03 UTC]
Assigned to the extension maintainer.
 [2008-11-27 14:50 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Jun 17 11:01:31 2024 UTC