I just checked and still fails in the same way - that is it fails and works alternately - with the latest from snaps, that is, a build dated 1014. Note I am using Windows, not Linux. I just also checked that it does work perfectly with my php5-RC1. I would try to build a debug build and look at the problem myself but my attempt to build with the soap extension enabled failed at the link step...I am not exactly sure what the right config options are. 

BTW we had a similar (but not identical) problem with the SDO extension that turned out to be our code calling xmlCleanupParser and reinstalling the default input handlers so they no longer went through PHP. That would cause the failures on every call from the second onward though. 

The exact code I am using, cut and pasted, is:
the client:

<?php
ini_set("soap.wsdl_cache_enabled", 0);
$client = new SoapClient("stockquote.wsdl", array("trace" => 1, "exceptions" => 0));
print($client->getQuote("ibm"));
?>

the server:<?php
$quotes = array("ibm" => 98.45);

function getQuote($symbol) {
	global $quotes;
	return $quotes[$symbol];
}

ini_set("soap.wsdl_cache_enabled", 0);

$server = new SoapServer("C:\Program Files\Apache Group\Apache2\htdocs\stockquote.wsdl");
$server->addFunction("getQuote");
$server->handle();

?>

The wsdl is a bit larger and is taken from the article, unchanged except for the 
    <soap:address location='http://localhost/server1.php'/> 
at the bottom.

Juts tried with RC3 and the problem is still there. I was able to build a debug build of the apache sapi and the soap extension with no problem though.

Windows pops up a dialog box to take you to the debugger. It claims there has been an access violation.

The call stack is 
NTDLL! 77f584ae()
_emalloc(unsigned int 10, char * 0x013656e8 `string', unsigned int 240, char * 0x00000000, unsigned int 0) line 182 + 63 bytes
_estrdup(const char * 0x00784518, char * 0x013656e8 `string', unsigned int 240, char * 0x00000000, unsigned int 0) line 403 + 25 bytes
sapi_get_default_content_type(void * * * 0x00b7b7a0) line 240 + 29 bytes
php_apache_request_ctor(request_rec * 0x005e2818, php_struct * 0x005e4060, void * * * 0x00b7b7a0) line 419 + 12 bytes
php_handler(request_rec * 0x005e2818) line 531 + 17 bytes
LIBHTTPD! 6ff0155f()

It breaks quite consistently at this point. 

I stepped through under the debugger and the problem goes away - don't they always.

sapi_get_default_context_type looks a pretty harmless piece of code that is just trying to get the default context type, and ultimately trying to do an estrdup of "test/html". I don't know why that should fail. 

I don't know why the SOAP client should provoke this failure  in the apache sapi. Neither do I know much about how the apache sapi is supposed to work so although I would like to help debug this problem I could do with some advice.

For info, still fails in the same way with RC4. I haven't rebuilt with debug to check that the call stack is the same, though.

I just checked RC4 from http://downloads.php.net/ilia/ and it works fine for me (Apache/1.3.28 (Win32) PHP/5.1.0RC4).

Probalby you have this bug because of missconfiguration.

The debug backtrace is not related to ext/soap.

Perhaps I have a bad configuration as you say but I don't know what sort of misconfiguration could cause a crash like this.

One possibility: perhaps you did not see the problem because you are running Apache 1.3 whereas I am running Apache 2 ... the threading is quite different. 

I agree the stack trace doesn't show SoapClient anywhere but using SoapClient does provoke the problem. The problem appeared when I moved from RC1 to RC2, so it is presumably some weakness in PHP RC2 and beyond which SoapClient uncovers.

Can you reproduce this with Linux? And NOT using some threaded  webserver since we don't really support that..

I just tried this on Linux, as requested, and the error does not occur there. I was using RC4. 

My colleague, Graham Charters, is also seeing this error on Windows. He has tried both Apache 2 and 1.3.33, with both RC4 and RC7 and we see the error repeatably.

We run into it so repeatably that I do not know why Ilia did not see it when he ran (Apache/1.3.28 (Win32) PHP/5.1.0RC4). 

We are wondering if it is something to do with the way we are building PHP. We rebuild even on Windows rather than use the pre-built binaries because we want to then go on and build our own extension. We will try and reproduce with a prebuilt binary...

We only support the pre-build binaries for windows. If you can reproduce this with those, reopen.

My colleague (Graham Charters) and I have been testing with prebuilt binaries on Apache 1.3. 

Graham's words follow (although I have also seen exactly the same result):

Further to Matthew's comments of Nov 22nd.  I've tested the sample Matthew referred to when opening this bug (client5/server1) against the following combination:

PHP 5.1 rc7 binary (Nov 23rd,7:30am GMT build) on Apache 1.3.33 Win32 on XP.  

The sample initially works fine, but on exactly the 50th run, it crashes Apache.  I have repeated this with my own rc7 build and see exactly the same result. A debug build causes the crash sooner, but it is always after a repeatable number of runs.

Reopening.

I tried yesterday with:
Apache/1.3.33 (Win32) PHP/5.1.0RC4 

and saw both the same effect Graham described (crash every fifty - yes fifty!) - also when I altered the script slightly got it to crash regularly every eight times. Just hit the refresh key enough times.


I quite accept that this is not likely to be really SoapClient's fault but something in the PHP engine.

Please try using this CVS snapshot:

  http://snaps.php.net/php5-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5-win32-latest.zip

Sorry, you probably only read the last append but the one immediately before said that we tried it with RC7 only yesterday.

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.

I already did this - it's lower down the bug report on 21st October and since the behaviour is unchanged I imagine that back trace is valid. Is there some other information you wanted that is not there?

Dmitry, check this out please.

I reproduced the bug on win32 with Apache, but I haven't any idea how to debug it. Seems like a win32 specific memory corruption. :(

Dmitry, thank you for reproducing the bug - that makes us feel that better that we are not just doing something stupid here.

Oddly, we find that it takes a different number of refreshes to reproduce the bug depending on whether we use InternetExplorer or Firefox. 

I have some time today and tomorrow so I will see if I can discover anything.

The bug is fixed in CVS HEAD and PHP_5_1.

The memory corruption was occur because zend_class_entry->static_members of internal classes were shared across threads.

Many thanks and well done for finding it. We agree it is fixed .