While i remember, something I did notice was the fact this segfault seems to only happen under MSIE on the PC, Firefox on Windows, and Linux. It does not crash when using a KHTML browser such as Safari 1.3, or Konqueror (I used the version from KDE 3.3).

No segfault occurs when I use the CLI. This is most odd as non of my code has anything that tries to sniff or do anything based on a specific browser. I'm sure the PHP code making it crash has nothing to do with the what browser is making the request. As you can see this is just one of many factors that seem to make this crash very hard for me to pin-point what is going wrong and provide sample PHP code. 

I am using Apache 2.0.46 and 2.0.52.

OK, I've tried to narrow down things a little more. This is not proving easy.

OK, I can see why this is making things crash according to different browsers. I have a piece of code like this ...

/**
 * Extracts path data from URL into a string.
 *
 * This will attempt to read the path data from many locations, 
 * such as after the .php part of the URL, the path request variable
 * or from the site root.
 */
function iq_extract_path() {
	if (!isset($_REQUEST['path'])) {
		/* try to extract it from URL */
		$path_string = $_SERVER['REQUEST_URI'];
		/* Are we hiding the .php file ? */
		if (strpos($_SERVER['SCRIPT_NAME'], '.php') !== false) {
			/* Remove the index or whatever .php bit */ 
			$path_string = preg_replace('/\/[\w]+.php/', '', $path_string);
		}
		/* We need to trim on / or it replaces '/' if we are running from root dir */
		$prefix_path = trim(dirname($_SERVER['SCRIPT_NAME']), '/');
		/* Remove any prefixed URL path */
		$path_string = str_replace($prefix_path, '', $path_string);
		/* remove query string */
		$path_string = str_replace('?'.$_SERVER['QUERY_STRING'], '', $path_string);
	} else {
		$path_string = $_REQUEST['path'];
	}
	return $path_string;
}

As you can see, this looks at server variables, which explains that. On the site it's used, it allows us to use a clean search engine / user friendly URL system, instead of using HTTP GET/POST variables for the front controller's dispatching. If no server variables are used, it looks at $_REQUEST['path'] as a safety fallback.

I found that setting $_REQUEST['path'] to the right value (so it doesn't touch the $_SERVER array) stops the segfault.

The segfault it's self is because of the SPL. I'm 99.99999% sure of this. zend_execute.c:1205 confirms this, and other scenarios where I get segfaults normally involve SPL ArrayAccess objects.

We use a template system, which is modelled as an object. This implements the ArrayAccess interface, so it makes it easy to set variables. It's initialized like this ...

$payment_schedule = new IQ_Template('admin/payment_schedule.xml');

we can poke data in like this...

$payment_schedule['schedule_year'] = $year;

likewise, there is some system in place where we can write custom web controls so it behaves like WACT / ASP.NETs template system.

Anyway, I found another way to prevent the crash, instead of setting $_REQUEST['path'] was to place ...

$payment_schedule = 'insert random string here';

before the line 

$payment_schedule = new IQ_Template('admin/payment_schedule.xml');

Despite the fact the additional line does nothing, it stops the segfault. I tried this after realising that the issue was related with a decreasing reference count due to _zval_ptr_dtor() being called.

I can't say this always happens always when assignments are made between two objects implementing ArrayAccess through the [] subscripts. However it does appear that there is always an ArrayAccess object with a [] subscript the left of the assignment operator at the point of the segfault.

Obviously this seems like a memory management issue at the heart of the variable managment / Zend engine's object overloading system, which explains it's complex, tricky nature as far as tracing is concerned.

I hope this is enough information. This is quite important issue to me as we often come across this issue in other places. Previously we've got round it by using temporary arrays to assign into and then copy that array into the object implementing array access (which is a nasty hack). Also being part of the internals/core of the Zend engine, is another reason see this as a pressing issue.

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

I normally do try and isolate bugs in PHP by producing a short few lines of PHP in order to replicate the problem.

I have tried on many occasions when I have had this bug to replicate it by stripping parts of the code down, but I have not managed to do it sucessfully yet. Is there any other way I can profide feedback? I could probably try and limit the amount code down to some extent, but even so I doubt it would be a small chunk of code.

Anyway, I will attempt to find a way to replicate this as soon as I can get time.

We can't do much without a script to reproduce it ourselves, so try come up with one..

In a worst case scenario (if I can't get a small test script developed), would it be OK to email you with access details to the scripts/server so you can investigate for yourself. I can give you suitable SSH access to our testing box. That way you can do what you want in the way of running gdb, recompiling etc if need be.

There seems to be no way I can reduce this bug down to a few lines. I can only think some eariler piece of code triggers some sort of memory corruption. I've tried with a test script, fiddling about with things like scopes and making circlar references, thinking maybe that was to do with it (seeing as it's destruction call to the offset that seems to be creating the problem, from what I can make out in the src)

Although I don't think it's the same thing as (Certainly I had some code that was doing what was said in these bugs, but it seems like it works now, which makes me believe the bugs below are different, although the behaviour is rather similar at times)...

http://bugs.php.net/bug.php?id=30346
OR
http://bugs.php.net/bug.php?id=32252

It is very similar. The issue is to do with offsetGet(). Frame 5 of the dump seems to the most likely problem area.

Are you using references extensively?

in what way?

In the template system I started to play about with, I did use reference operators explictly, much like PHP4. However, since then I haven't used them in other bits of code. I did find that occasionally that using the reference operators did screw things up a while back, and I have had issues such as the one in at http://bugs.php.net/bug.php?id=32745. However the points in which I have used the reference operator, they have nearly always been dealing with objects, and not POD types such as string/int/float types, and therefore would be naturally be passed by reference regardless of there being a reference operator.

Out of interest, what way do references affect things internally?

Hi Derick,

You're a ledgend! I was having to do some changes to some of the code that was crashing. Funnily enough I changed some and decided I'd use a reference to an array element. All of a sudden the segfaults returned, and I did a backtrace on our live server (for some reason, probably relating to my clumsiness, the test box doesn't give us backtraces despite compiling with --enable-debug). The backtrace gives exactly the same results.

It seems the segfault does not happen though until further down in the program. I would guess it does it where some of the ArrayAccess stuff is used.

I'll see if I can develop a test script again to reproduce this bug, now I have a clearer idea what seems to be causing it.

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".