Bug #71129 [ReO]: Segmentation fault on ZTS Embed SAPI
[email protected] ("maroszek at gmx dot net")
| Newsgroups | php.bugs |
|---|---|
| Message-ID | <[email protected]> |
Edit report at https://bugs.php.net/bug.php?id=71129&edit=1 ID: 71129 User updated by: maroszek at gmx dot 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 11.11 +Operating System: OS X 10.11 PHP Version: 7.0.0 Block user comment: N Private report: N New Comment: 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) Previous Comments: ------------------------------------------------------------------------ [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] [email protected] 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] [email protected] 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" ------------------------------------------------------------------------ [2015-12-20 14:35:54] [email protected] @maroszek thanks for the check, a patch is now commited. I'm setting the status onto feedback as you have yet more issues. Unfortunately I've no Mac to test it. But how it sounds like, the crash and the timeout issues are two separate things. As from your code, the requests should not be hanging but just running through, so no timeouts are expected. Though, as you've already said, Mac will use another threading library, so maybe it could condition the issue, but just a guess. You probably should debug through and check which request are not running through and why. Maybe there's a way to reproduce this on Linux as well. So set this to feedback, but i'd rather suggest to indeed close this one and to open another ticket for the exact timeout issue you experience. Please feel free to do so if you think it's ok. Thanks. ------------------------------------------------------------------------ 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