0000609: Xdebug messe up with fatal to exception error conversions with PHP SoapClient

Notes
(0001564) derick (administrator) 2010-08-18 16:04	You're using an outdated version of Xdebug, please try 2.1.0 first. This bug is listed as fixed in 2.1.0beta1.

(0001574) tvlooy (reporter) 2010-09-14 11:43	I have this problem Xdebug v2.1.0 / PHP 5.3.2-1ubuntu4.2

(0001583) tvlooy (reporter) 2010-10-14 10:08	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 <?php xdebug_disable(); 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 <?php //xdebug_disable(); 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.

(0001615) dalexandre (reporter) 2010-11-22 13:47	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).

(0001724) maartenReactCom (reporter) 2011-04-14 12:10	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...

(0001769) jhedstrom (reporter) 2011-08-02 21:55	This is still broken in 2.1.2.

(0001827) jboffel (reporter) 2011-10-02 00:49 edited on: 2011-10-02 00:54	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.

(0001830) jboffel (reporter) 2011-10-03 00:28 edited on: 2011-10-06 01:03	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...

(0001837) jboffel (reporter) 2011-10-09 13:08 edited on: 2011-10-09 13:49	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.

(0001841) jboffel (reporter) 2011-10-10 09:24	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.

(0001856) derick (administrator) 2011-11-11 23:50	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 14:30	dalexandre	New Issue
2010-08-18 14:30	dalexandre	Operating System	=> Ubuntu Linux
2010-08-18 14:30	dalexandre	PHP Version	=> 5.3.2
2010-08-18 14:30	dalexandre	Xdebug Version	=> 2.0.5
2010-08-18 16:04	derick	Note Added: 0001564
2010-08-18 16:04	derick	Status	new => feedback
2010-09-14 11:43	tvlooy	Note Added: 0001574
2010-10-14 10: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 12:10	maartenReactCom	Note Added: 0001724
2011-08-02 21:55	jhedstrom	Note Added: 0001769
2011-10-02 00:49	jboffel	Note Added: 0001827
2011-10-02 00:50	jboffel	File Added: xdebug_stack.c
2011-10-02 00:54	jboffel	Note Edited: 0001827	View Revisions
2011-10-03 00:28	jboffel	Note Added: 0001830
2011-10-03 00:33	jboffel	File Added: xdebug_stack-v2.c
2011-10-06 01:03	jboffel	Note Edited: 0001830	View Revisions
2011-10-09 13:05	jboffel	File Added: xdebug_stack-v3.c
2011-10-09 13:08	jboffel	Note Added: 0001837
2011-10-09 13:49	jboffel	Note Edited: 0001837	View Revisions
2011-10-10 09: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