Please cut the script down to minimum code (and without the HTML) that can reproduce the error. Is this reproduceable running via CLI instead of within apache? Also a backtrace would be useful as I cant reproduce this in Linux or Windows.

OK, I've updated the tar ball:

http://jessen.ch/files/php-problem-sep2007.tar.gz

There are now only 5 lines of PHP code. The included file is empty as is the XSLT stylesheet. I'm pretty certain the problem is actually caused by the virtual() call, but it doesn't manifest itself till later.

I ran apache with gdb to produce this backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1214642496 (LWP 26256)]
0xb77fa792 in zend_get_executed_lineno () from /usr/lib/apache2/mod_php5.so
(gdb) bt
#0  0xb77fa792 in zend_get_executed_lineno () from /usr/lib/apache2/mod_php5.so
#1  0xbfa1fcd8 in ?? ()
#2  0xb7809e05 in zend_error_noreturn () from /usr/lib/apache2/mod_php5.so
#3  0xb7809e05 in zend_error_noreturn () from /usr/lib/apache2/mod_php5.so
#4  0xb77c0fd4 in php_verror () from /usr/lib/apache2/mod_php5.so
#5  0xb77c14df in php_error_docref0 () from /usr/lib/apache2/mod_php5.so
#6  0xb76e6656 in php_libxml_structured_error_handler () from /usr/lib/apache2/mod_php5.so
#7  0xb76e66bc in php_libxml_error_handler () from /usr/lib/apache2/mod_php5.so
#8  0xb6bfbcac in xsltTransformError () from /usr/lib/libxslt.so.1
#9  0xb6bf87e4 in xsltParseStylesheetProcess () from /usr/lib/libxslt.so.1
#10 0xb6bf92cd in xsltParseStylesheetImportedDoc () from /usr/lib/libxslt.so.1
#11 0xb6bf939a in xsltParseStylesheetDoc () from /usr/lib/libxslt.so.1
#12 0xb6ca3918 in zif_xsl_xsltprocessor_import_stylesheet () from /usr/lib/php5/extensions/xsl.so
#13 0xb783909b in execute () from /usr/lib/apache2/mod_php5.so
#14 0xb7829a98 in execute () from /usr/lib/apache2/mod_php5.so
#15 0xb78087e3 in zend_execute_scripts () from /usr/lib/apache2/mod_php5.so
#16 0xb77c2570 in php_execute_script () from /usr/lib/apache2/mod_php5.so
#17 0xb788ea4d in php_ap2_register_hook () from /usr/lib/apache2/mod_php5.so
#18 0x800327ad in ap_run_handler () from /usr/sbin/httpd2-prefork
#19 0x80036217 in ap_invoke_handler () from /usr/sbin/httpd2-prefork
#20 0x8004247e in ap_process_request () from /usr/sbin/httpd2-prefork
#21 0x8003f278 in ap_register_input_filter () from /usr/sbin/httpd2-prefork
#22 0x8003a83d in ap_run_process_connection () from /usr/sbin/httpd2-prefork
#23 0x80046c67 in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork
#24 0x80046f4a in ap_graceful_stop_signalled () from /usr/sbin/httpd2-prefork
#25 0x80047e51 in ap_mpm_run () from /usr/sbin/httpd2-prefork
#26 0x8001dd4b in main () from /usr/sbin/httpd2-prefork

Does the crash happen in CLI?

The reproduce script requires virtual() which isn't available in CLI.

updated summary.
The xsl code just exposes the problem caused by the virtual call.

You need to provide us a short but complete example script which can be used to reproduce this problem.

Yes, I already did back on 14 September.  The tarball is the same: http://jessen.ch/files/php-problem-sep2007.tar.gz

Cut'n'paste of the code needed:

<?php
virtual("problem-include"); // How?
if (FALSE===($xp=new XSLTProcessor())) die("unable to create xslt engine");
$xsl=new DOMDocument;
$xsl->load("empty.xsl");
$xp->importStyleSheet($xsl);
?>

I'm not sure how to use the files in that tar ball..I guess you have some complex multiviews configuration also in there?
Can you please try to cut down all the external stuff to minimum, ie. without using some fancy Apache configurations?

Does the crash happen if you have some other error? ie. without using XSL?

My apache config is nothing particularly fancy, I just do plain language negotiation. Still, I've updated the reproduce code:

http://jessen.ch/files/php-bug42666-oct2007.tar.gz

And does the problem occur without XSL (by causing some other error) ?
(I can't check the tar package right now)

Sorry, forgot to mention that - yes, I've removed the XSL calls, and added a plain syntax error. The segfault still happens.

So you should be able to now provide the reproducing script here instead of the tar package?

Sure. 

problem.phtlm.en:

<?php
        virtual("problem-include.phtml.en");
        klop
?>

problem-include.phtml.en:

<?php
?>

Similar issue running PHP 5.2.4 as a module with Apache 2.2.6 on a Win XP box. Three files:

---

test.php:
<?php
virtual ('/test.html');
echo $bad;?>

test.html:
<!--#include virtual="test2.php" -->

test2.php:
<?php

?>

---
This is running with display_errors=On. It also segfaults, but in different ways, with display_errors=Off, or depending on the exact amount of bytes/calls in various files will simply print out a notice with a corrupted linenumber.

It looks like the issue is that the php-within-php virtual nesting somehow corrupts php's ability to tell the difference between uninitialized/unset variables and valid ones, leading to memory access exceptions of various sorts.

Please try using this CVS snapshot:

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

  http://windows.php.net/snapshots/

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".