Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70560
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.51 as permitted sender)
Message-ID: <1386611095.9685.15.camel@smugmug>
To: Ralph Schindler <ralph@ralphschindler.com>, Nikita Popov
	 <nikita.ppv@gmail.com>, Dmitry Stogov <dmitry@zend.com>
Cc: internals <internals@lists.php.net>
Date: Mon, 09 Dec 2013 18:44:55 +0100
In-Reply-To: <52A5FD1B.2020301@ralphschindler.com>
References: <52A5FD1B.2020301@ralphschindler.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] SegFault 11 on 5.5.6 on function return
From: mike.php.net@gmail.com (Mike)

On Mon, 2013-12-09 at 11:25 -0600, Ralph Schindler wrote:
> Hi all,
> 
> We started noticing Segfaults in Travis when PHP was upgraded to 5.5.6. 
>   I've tested this particular issue on both linux and mac and can 
> produce the segfault in both place.
> 
> Looking at the backtrace (provided), can anyone offer assistance as to 
> what changed between 5.5.5 and 5.5.6 that might be causing this?
> 
> I've been able to isolate the last line of PHP code that executes before 
> the segfault:
> 
>  
> https://github.com/sebastianbergmann/phpunit/blob/3.7/PHPUnit/Util/Type.php#L203
> 
> I know the value of $value there to be null when this SegFault occurs.
> 
> Also, the backtrace seems to hint at a problem in the garbage collector 
> since the source of the issue emanates from gc_remove_from_buffer().
> 
> My guesses...
> 
> Is it possible that either the garbage collector is running and 
> destroying the stack, and that when unwinding the stack frames it is in 
> an inconsistent state and/or the return value for that particular 
> function is not placed on the stack so that the stack is in the proper 
> context when the return is processed?
> 
> I can do additional research if anyone would like to point me in the 
> right direction, or I can provide access to a VM where this particular 
> backtrace was produced from.
> 
> Thanks in advance.
> -ralph

RETVAL_ZVAL_FAST comes to mind.... Nikita, Dmitry?

-- 
Regards,
Mike