# SegFault 11 on 5.5.6 on function return - Thread: https://externals.io/message/70558 - Original archive: https://news-web.php.net/php.internals/70558 - Started by Ralph Schindler on 2013-12-09T17:25:47+00:00 - Messages: 9 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #70558 — Ralph Schindler — 2013-12-09T17:25:47+00:00 URL: https://externals.io/message/70558#70558 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 --- ## #70559 — Ralph Schindler — 2013-12-09T17:34:50+00:00 URL: https://externals.io/message/70558#70559 · In reply to: #70558 > 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? Sorry for double-post, but it might be helpful to have a backtrace without xdebug, (attached). -ralph --- ## #70560 — Mike — 2013-12-09T17:44:55+00:00 URL: https://externals.io/message/70558#70560 · In reply to: #70558 > 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 --- ## #70561 — Mike — 2013-12-09T17:49:23+00:00 URL: https://externals.io/message/70558#70561 · In reply to: #70560 > RETVAL_ZVAL_FAST comes to mind.... Nikita, Dmitry? > Sorry, this change is obviously 5.6 -- Regards, Mike --- ## #70564 — Dmitry Stogov — 2013-12-09T18:22:04+00:00 URL: https://externals.io/message/70558#70564 · In reply to: #70561 RETVAL_ZVAL_FAST was introduced in PHP-5.6 only. Dmitry. > > > > […] > > Sorry, this change is obviously 5.6 > > -- > Regards, > Mike --- ## #70566 — Julien Pauli — 2013-12-09T18:48:07+00:00 URL: https://externals.io/message/70558#70566 · In reply to: #70559 On Mon, Dec 9, 2013 at 6:34 PM, Ralph Schindler wrote: > Looking at the backtrace (provided), can anyone offer assistance as to > > […] > > Sorry for double-post, but it might be helpful to have a backtrace without > xdebug, (attached). Can you confirm that the bug is *not* in 5.5.5 but 5.5.6 only ? Thx. Julien Pauli --- ## #70567 — Ralph Schindler — 2013-12-09T18:58:11+00:00 URL: https://externals.io/message/70558#70567 · In reply to: #70566 > Can you confirm that the bug is *not* in 5.5.5 but 5.5.6 only ? I wouldn't say I can confirm that conclusively. With 5.5.5 compiled the exact same way on my mac, I do not get the segfault. Given the class of problem though- I think that me not being able to reproduce should be considered anecdotal. Dmitry was able to locally confirm the issue in PHP-5.5 and said he'd look at it tomorrow in more depth. He used valgrind to identify problems in the 5.5 branch. I think his methods (valgrind, extensive gdb introspection) will produce a more reliable idea of what is actually going wrong and when it might have been introduced. Thanks, -ralph --- ## #70594 — Ralph Schindler — 2013-12-11T20:09:05+00:00 URL: https://externals.io/message/70558#70594 · In reply to: #70558 > 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? Just to close this out, it ended up being an parameter handling bug in ext/soap that Dmitry fixed and will be available in 5.5.8. -ralph --- ## #70600 — Julien Pauli — 2013-12-12T10:27:33+00:00 URL: https://externals.io/message/70558#70600 · In reply to: #70594 On Wed, Dec 11, 2013 at 9:09 PM, Ralph Schindler wrote: > > Looking at the backtrace (provided), can anyone offer assistance as to > > […] > > Just to close this out, it ended up being an parameter handling bug in > ext/soap that Dmitry fixed and will be available in 5.5.8. Ok, thx for this. Julien