Bug #71129 [ReO]: Segmentation fault on ZTS Embed SAPI

From: Date: Mon, 11 Jan 2016 17:33:37 +0000
Subject: Bug #71129 [ReO]: Segmentation fault on ZTS Embed SAPI
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-198576@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=71129&edit=1

 ID:                 71129
 Updated by:         ab@php.net
 Reported by:        maroszek at gmx dot net
 Summary:            Segmentation fault on ZTS Embed SAPI
 Status:             Re-Opened
 Type:               Bug
 Package:            Reproducible crash
 Operating System:   OS X 10.11
 PHP Version:        7.0.0
 Block user comment: N
 Private report:     N

 New Comment:

@maroszek With the segfault part, could you please check this patch? https://gist.github.com/weltling/e0922914dca8c8ee1886
If possible, please also test CLI and Apache. On my side, I was checking your embed implementation
on windows and linux with TS/NTS CLI and Apache as well, none of those shows an issue.

With the timeout part - i guess that your theory is not correct. What the while(true) loop does is
constantly processing the requests with the empty.php file. There is per se neither timeout, nor any
signal expected. It might be a race condition that block a request, so then it gets signaled after
30 seconds. I've got no OSX to investigate on this :( I guess there have to be some native OSX
tools for such cases. What I could also imagine that it could also be some OS specific issue with
the threading library, maybe if you explicitly link pthreads on OSX, it'll differ? 

Thanks.


Previous Comments:
------------------------------------------------------------------------
[2015-12-25 20:04:37] maroszek at gmx dot net

This really seems to be related to signaling, which seems to behave different on OS X. 

Disabling max_executing_time (or adding a simple return; in zend_bailout) seems to workaround the
problem.

Line for the crash.cpp sample
> php_embed_module.ini_entries = "max_execution_time=0\n\0";

Do you know if the signal handler (zend_timeout) needs to be called in the same thread as the timed
out script? (This does not seem to be the case for OS X)

There seems to be a known bug in SIGPROF on OS X, but as far as i have understood, it should be
fixes for El Capitan and therefore not the problem in my case. (http://research.swtch.com/macpprof)

------------------------------------------------------------------------
[2015-12-21 13:02:36] maroszek at gmx dot net

Most often the request does not block but throws the error immediately. Therefore OS X might be
*faster* somewhere and have a race condition, which checks for the timeout...

------------------------------------------------------------------------
[2015-12-21 12:20:28] ab@php.net

Hi,

yeah, reverted because i've seen there are some issues with CLI and it is definitely leaking in
the main thread on any SAPI. Also this is not appropriate for the NTS builds. Have to do yet another
round to collect all the cases, also in regard to #71115.

With the timeout - your code doesn't change the default ini, so it's 30 seconds. With an
empty script that should never be the case, because the request should just run through and exit.
But something blocks in the request, whether some lock or whatever, so then it hands 30 seconds and
then gets bailed out. For Mac, there are for sure some native tools which possible would do a better
job?

Thanks.

------------------------------------------------------------------------
[2015-12-21 11:52:04] maroszek at gmx dot net

I have seen that you have reverted the patch. Did you have any more information why it fails on OS
X?

But I think my segfault does not relate to the other mentioned bug, because this one was already
present in PHP 5.x. (AFAIK the other bug depends on the new PHP7 zend_strings ref count...)

My current theory:
Some timer does not behave corretly and falsely detects a script timeout. (the original bug) This
leads to an invalid cleanup or a double free/double cleanup. 

Unfortunately valgrind under OS X does not detect any issues... drd/helgrind detects some issues,
but i haven't validated those yet and as some of them are present in linux aswell so they might
be just more false positives.

------------------------------------------------------------------------
[2015-12-21 11:11:20] ab@php.net

Automatic comment on behalf of ab
Revision: http://git.php.net/?p=php-src.git;a=commit;h=53bfb6618d13083b769014cbdcb845f787a7cf28
Log: Revert "Partially fix bug #71129"

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    https://bugs.php.net/bug.php?id=71129


--
Edit this bug report at https://bugs.php.net/bug.php?id=71129&edit=1


Thread (32 messages)

« previous php.bugs (#198576) next »