View Issue Details

IDProjectCategoryView StatusLast Update
0000609XdebugUncategorizedpublic2011-11-11 23:50
ReporterdalexandreAssigned Toderick 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version2.0.0dev 
Target VersionFixed in Version 
Summary0000609: Xdebug messe up with fatal to exception error conversions with PHP SoapClient
DescriptionWith Xdebug enabled, SoapClient doesn't anymore send catchable Exception when an invalid WSDL is provided (webservice can be down, that's a real world case).

try {
  $sc = new SoapClient("some-wrong.wsdl", array('exceptions' => true));
} catch (Exception $e) {
  echo 'Error Caught :-)';

Will return uncatchable Fatal Error :

PHP Fatal error: SOAP-ERROR: Parsing WSDL: Couldn't load from 'some-wrong.wsdl' : failed to load external entity "some-wrong.wsdl" ...

Uncomment the xdebug_disable() line and the error is catched.
Additional InformationThis bug seems to be linked to
TagsNo tags attached.
Operating SystemUbuntu Linux
PHP Version5.3.2


has duplicate 0000705 resolvedderick SoapClient constructor does not throw exception where it should 



2010-08-18 15:04

administrator   ~0001564

You're using an outdated version of Xdebug, please try 2.1.0 first. This bug is listed as fixed in 2.1.0beta1.


2010-09-14 10:43

reporter   ~0001574

I have this problem Xdebug v2.1.0 / PHP 5.3.2-1ubuntu4.2


2010-10-14 09:08

reporter   ~0001583

The test case given by dalexandre is still valid, see below:

[tvl@iron ~/Desktop]
$ php --version
PHP 5.3.3-1ubuntu9 with Suhosin-Patch (cli) (built: Sep 20 2010 20:39:59)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
    with Xdebug v2.1.0, Copyright (c) 2002-2010, by Derick Rethans
[tvl@iron ~/Desktop]
$ cat test.php
try {
  $sc = @new SoapClient("some-wrong.wsdl");
} catch (Exception $e) {
  echo "Error Caught :-)\n";

[tvl@iron ~/Desktop]
$ php test.php
Error Caught :-)
[tvl@iron ~/Desktop]
$ vi test.php
[tvl@iron ~/Desktop]
$ cat test.php
try {
  $sc = @new SoapClient("some-wrong.wsdl");
} catch (Exception $e) {
  echo "Error Caught :-)\n";

[tvl@iron ~/Desktop]
$ php test.php
[tvl@iron ~/Desktop]

So, with xdebug enabled, the error is not caught by the try/catch anymore.


2010-11-22 13:47

reporter   ~0001615

I can't update the bug report, but as tvlooy mention it,
even with xdebug 2.1.0 I still have this issue.

I think it could be interessting to mention that i'm using dotdeb repository (php5-xdebug_5.3.3-0.dotdeb.1_i386.deb).


2011-04-14 11:10

reporter   ~0001724

This is still broken, also in 2.1.1

I even believe this isn't a 'minor' issue, because this just means that the 'exceptions' option is broken. Using exceptions really forces you to add a xdebug_disable() call...


2011-08-02 20:55

reporter   ~0001769

This is still broken in 2.1.2.


2011-10-01 23:49

reporter   ~0001827

Last edited: 2011-10-01 23:54

View 2 revisions

Hi, I confirm this bug still exists in last version because the fix made in past couldn't solve the problem at my sense. Couldn't get a SOAPACTION header in client mode.
I tried a patch, ugly, but working, to solve that situation and back to old error handler when SOAP is in use.
I admit I couldn't figure out a better way to solve the problem if we want to keep the stack trace overloading of xdebug...
Other way would be to give up on xdebug overloding of error message :(
I uploaded the xdebug_stack.c modified for 2.1.2

In my patch I doesn't include treatment for the SoapServer type error because first patch in xdebug.c is supposed at least to solve that part. But normally if we want to centralize detection, possible to add a strstr on "SoapServer::Soap" I guess.


2011-10-01 23:50


xdebug_stack.c (37,585 bytes)


2011-10-02 23:28

reporter   ~0001830

Last edited: 2011-10-06 00:03

View 2 revisions

I attached new version of the patch to make it more stable and covering all cases, still ugly though but seems to works well...

I've to say also that this patch will make stack trace overload in error message available only in exception mode of the soap client, if you decide to raise a fatal error, then no xdebug stack trace.
So it could say it's doing half of the job, I'm not sure it is better than not do at all only in case of soap error...


2011-10-02 23:33


xdebug_stack-v2.c (37,774 bytes)


2011-10-09 12:05


xdebug_stack-v3.c (38,897 bytes)


2011-10-09 12:08

reporter   ~0001837

Last edited: 2011-10-09 12:49

View 2 revisions

Hi, I had a little time to work more on it so I got a 3rd version of the patch that is, this time I believe, clean :)

It's more evolved as it checks if last stack entry is a class with name SoapClient or SoapServer, also it'll check if soap php extension is in used, that should proof that it is the native SoapClient or SoapServer provided by php and not some user defined class in PHP language.

It's still missing a little something to make it perfect though, it could be nice to find a way to check current soap configuration context to know if the user is asked soap extension to raise an exception or just a php error... For now I not yet figured out a clean way to do it.


2011-10-10 08:24

reporter   ~0001841

derick, do you know if there is a way to use the object store in executor_global->current_execute_data ?
I tried many things but seems that object is already destroyed or can't be accessed anymore...
If we wanted to know if we have to run xdebug error handler or not, we need to access the SoapClient or SoapServer object properties, as soap module add a property to the object to say if it has to raise exception or not...
So I tried to use get_properties function from the object handler stored in executor_global->current_execute_data but it makes segfault...
I guess I misunderstood something or context is not accessible anymore. If so, it's impossible to use xdebug error handler properly with soap error error handler at same time.


2011-11-11 23:50

administrator   ~0001856

I've implemented in a slightly different way, but it should work. Please test the code on github (either master, or xdebug_2_1).

Issue History

Date Modified Username Field Change
2010-08-18 13:30 dalexandre New Issue
2010-08-18 13:30 dalexandre Operating System => Ubuntu Linux
2010-08-18 13:30 dalexandre PHP Version => 5.3.2
2010-08-18 13:30 dalexandre Xdebug Version => 2.0.5
2010-08-18 15:04 derick Note Added: 0001564
2010-08-18 15:04 derick Status new => feedback
2010-09-14 10:43 tvlooy Note Added: 0001574
2010-10-14 09:08 tvlooy Note Added: 0001583
2010-11-22 13:47 dalexandre Note Added: 0001615
2010-11-22 13:47 dalexandre Status feedback => new
2011-04-14 11:10 maartenReactCom Note Added: 0001724
2011-08-02 20:55 jhedstrom Note Added: 0001769
2011-10-01 23:49 jboffel Note Added: 0001827
2011-10-01 23:50 jboffel File Added: xdebug_stack.c
2011-10-01 23:54 jboffel Note Edited: 0001827 View Revisions
2011-10-02 23:28 jboffel Note Added: 0001830
2011-10-02 23:33 jboffel File Added: xdebug_stack-v2.c
2011-10-06 00:03 jboffel Note Edited: 0001830 View Revisions
2011-10-09 12:05 jboffel File Added: xdebug_stack-v3.c
2011-10-09 12:08 jboffel Note Added: 0001837
2011-10-09 12:49 jboffel Note Edited: 0001837 View Revisions
2011-10-10 08:24 jboffel Note Added: 0001841
2011-11-11 23:50 derick Note Added: 0001856
2011-11-11 23:50 derick Status new => closed
2011-11-11 23:50 derick Assigned To => derick
2011-11-11 23:50 derick Resolution open => fixed
2012-01-06 18:41 derick Relationship added has duplicate 0000705
2016-07-31 12:36 derick Category Usage problems => Usage problems (Crashes)
2016-07-31 12:38 derick Category Usage problems (Crashes) => Usage problems (Wrong Results)
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized