
Bug #69326 SIGSEGV (signal 11, Segmentation fault) in zend_string.h
Submitted: 2015-03-29 05:28 UTC Modified: 2015-04-12 05:13 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: pegasus at vaultwiki dot org Assigned:
Status: Open Package: Reproducible crash
PHP Version: master-Git-2015-03-29 (Git) OS: Centos 6 64-bit
Private report: No CVE-ID: None
View Add Comment Developer Edit
Your email address:
Solve the problem:
40 - 22 = ?
Subscribe to this entry?

 [2015-03-29 05:28 UTC] pegasus at vaultwiki dot org
A SIGSEGV appears in my php-fpm log files several times a day. I don't know which script is causing it, or what other effects it might be having. I managed to get the following backtrace.

Note that I am unable to follow the instructions for "Locating which function call caused a segfault" here:

It seems that these instructions are either outdated or are not relevant for this particular segfault. Any ideas?

Actual result:
#0  0x0000000000967202 in zend_mm_alloc_small (heap=0x7f44bd800040,
    size=64, bin_num=7,
    __zend_filename=0xf98a68 "/root/php-src-1646e0e/Zend/zend_string.h",
    __zend_lineno=97, __zend_orig_filename=0x0, __zend_orig_lineno=0)
    at /root/php-src-1646e0e/Zend/zend_alloc.c:1232
#1  0x0000000000967469 in zend_mm_alloc_heap (heap=0x7f44bd800040,
    __zend_lineno=97, __zend_orig_filename=0x0, __zend_orig_lineno=0)
    at /root/php-src-1646e0e/Zend/zend_alloc.c:1299
#2  0x00000000009696be in _emalloc (size=32,
    __zend_lineno=97, __zend_orig_filename=0x0, __zend_orig_lineno=0)
    at /root/php-src-1646e0e/Zend/zend_alloc.c:2208
#3  0x0000000000989787 in zend_string_alloc (len=6, persistent=0)
    at /root/php-src-1646e0e/Zend/zend_string.h:97
#4  0x00000000009927c0 in concat_function (result=0x7f44bd828a70,
    op1=0x7f44bd828980, op2=0x7f4480831e10)
    at /root/php-src-1646e0e/Zend/zend_operators.c:1555
#5  0x0000000000a3903e in ZEND_CONCAT_SPEC_CV_CONST_HANDLER (
    at /root/php-src-1646e0e/Zend/zend_vm_execute.h:27768
#6  0x00000000009f181c in execute_ex (ex=0x7f44bd827030)
    at /root/php-src-1646e0e/Zend/zend_vm_execute.h:394
#7  0x00000000009f1972 in zend_execute (op_array=0x7f44bd871000,
    return_value=0x0) at /root/php-src-1646e0e/Zend/zend_vm_execute.h:434
#8  0x000000000099b34c in zend_execute_scripts (type=8, retval=0x0,
    file_count=3) at /root/php-src-1646e0e/Zend/zend.c:1355
#9  0x000000000090a8cb in php_execute_script (primary_file=0x7fff4d767490)
    at /root/php-src-1646e0e/main/main.c:2519
#10 0x0000000000a702b3 in main (argc=8, argv=0x7fff4d7676b8)
    at /root/php-src-1646e0e/sapi/fpm/fpm/fpm_main.c:1891


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-03-29 07:16 UTC]
-Status: Open +Status: Feedback
 [2015-03-29 07:16 UTC]
need a short but complete example script to be able to reproduce
this bug ourselves. 

resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

if no reproduce script, we can't do much thing on this...
 [2015-03-29 08:59 UTC]
To get a userland backtrace, switch to the execute_ex frame "f 6", load gdb macros "source path/to/php-src/.gdbinit" and run "zbacktrace execute_data".
 [2015-03-29 13:29 UTC] pegasus at vaultwiki dot org
Thanks for the info. After seeing the userland backtrace, I have little faith of being able to create a script that can reproduce this. According to the backtrace, the offending line is 195 in a particular script:
$obj_key = $type . '/' . $class;

Which appears in this context:
	public static function fetch_object($type, $class, $dependency = '', $always_instantiate = false)
		static $object = array();

		$obj_key = $type . '/' . $class; // SEGFAULT?

		if ($dependency AND $class != 'Dependency')
			$obj_key .= '/' . $dependency;

The backtrace claims that $type = 'Model' and $class = 'Node' when it is passed to ::fetch_object
From a userland perspective, anything above this context in the stack should not have an effect here.

Since not only does this code run in production flawlessly 99.9% of the time for this and other arguments, I cannot see being able to concatenate any simple string like this in an attempt to cause a segfault for a test script without understanding the way the internals work.

Further, this is going off of the line numbers provided by the backtrace that in some cases are blatantly wrong. I have noticed in recent builds of PHP that line numbers associated with errors in general tend to be completely wrong. Hoping you sort out the issue with line numbers soon.
 [2015-03-30 10:49 UTC]
The linenos in zbacktrace may well be wrong - the implementation is not very complete. But I'm not aware of incorrect line numbers for normal errors. Can you maybe post an example?
 [2015-04-01 20:02 UTC] pegasus at vaultwiki dot org
Apologies, the line numbering issue I had noted was actually an issue with the way my code viewer counted lines. I have switched viewers, and the line numbers given by userland errors are now correct.

In my last reply I mentioned the segfault occurred on line 195 in my script. Using the correct line numbers, line 195 is the closing brace in the last line of the snippet I provided.

I should also mention that in this case, the backtrace claims that $dependency is passed explicitly as "" (not just using the default value).

I believe I have located the site URL that leads to this the segfault, so I can start stepping through the calling script and see if there's anything unusual going on.
 [2015-04-02 04:05 UTC] pegasus at vaultwiki dot org
I was able to resolve the segfault by making a small change to the script. Unfortunately, it is a very large script and the segfault seemed to occur only with certain data sets -- I could not reproduce the segfault on a separate installation or by using a smaller test script. I compared the data sets that segfaulted to sets that didn't and there were no differences or irregularities that I could see.

However, here is the test script I made that demonstrates the kinds of operations the script performs, as well as where the segfault occurs (while this test doesn't actually segfault):

class Info_Object

class Item_Object
	protected $infoid = 0;

	public function getInfoId()
		$this->infoid = 1;

		return $this->infoid;

function fetch_info(&$infoid)
	global $infocache;

	$infoid = intval($infoid);

	if (!isset($infocache["$infoid"]))
		$infocache["$infoid"] = array(
			'contentid' => 1,
			'title' => 'Content'

		$shortcut =& $infocache["$infoid"];

	// other code here was the backtrace in the core dump
	// such as
	$infocache["$infoid"]['itemid'] = $infoid;

	// but when walking through, we learned that the segfault was later

	return $infocache["$infoid"]; // segfault

$view = new Info_Object();
$view->item = new Item_Object();
$view->infoid = $view->item->getInfoId();

if ($view->infoid)
	$info = fetch_info($view->infoid);

echo 'SUCCESS';

I was able to resolve the segfault by modifying this line:
$info = fetch_info($view->infoid);

So that the new line was like so:
$infoid = $view->infoid;
$info = fetch_info($infoid);

Hopefully this gives a clue as to where to look.
 [2015-04-12 04:22 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
information that was requested earlier, please do so and
 [2015-04-12 05:13 UTC]
-Status: No Feedback +Status: Open
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Wed Jul 17 04:01:25 2019 UTC