Hi, Thank you very much,We started a ZF2 project a few months ago using ZF2 2.1.5 and php 5.4. Everything was going well until we tried to upgrade ZF2 to version 2.2.* We first tried with version 2.2.2 and then recently 2.2.4. The website runs fine for a few minutes, up to a few hours, and it segfaults. We currently run php 5.4.19 on Ubuntu Precise on Apache 2.2 and mod_php. We made sure that we ONLY upgraded ZF2, and nothing else changed at the same time. The problem is that segfault doesn't happen immediately, it sometimes takes a few hours, but once it happens it keeps segfaulting. We are also unable to reproduce the problem on our dev environment despite using exactly the same software versions. I know that a segfault problem is a bug in php, not ZF2, I'm asking here to try to have a clue on how to reproduce the problem. I created a core dump, but I doubt it's going to be very useful without a reliable way to reproduce the problem. It looks like the segfault happens in zend_alloc.c. As it only happens after a while we thought it might be related to the garbage collection. We tried setting zend.enable_gc=0 and that seems to delay the problem, but eventually it still happens. Any clue of something that changed from 2.1.5 to 2.2.* that might cause this issue? Giacomo |
Did you try changing also the *MINOR* 2.2 version? That may help discovering what the failure actually is. On Wed, Sep 4, 2013 at 11:55 AM, Giacomo Orlandi <[hidden email]> wrote:
|
We tried with ZF2 2.2.2 and 2.2.4 and we had the same issue. Should we try also with 2.2.0 or 2.2.1?On 4 September 2013 11:03, Marco Pivetta <[hidden email]> wrote:
|
Yes please. Otherwise, the scope is still too broad. On Wed, Sep 4, 2013 at 12:10 PM, Giacomo Orlandi <[hidden email]> wrote:
|
In reply to this post by Marco Pivetta
I've noticed eventual but consistent segfaults when using file uploads in conjunction with the buildin (as of php5.4) session upload progress feature. Whenever I switched to Apc upload progress the problem disappears. And i stopped searching... Somehow this ties into closing the session as these are destroyed too in those situations. Hope this help a bit. Bas Kamer
|
Marco: it did segfault on 2.2.1, we are trying with 2.2.0 now. Bas: we are not using the session upload progress feature.On 4 September 2013 11:14, Bas Kamer <[hidden email]> wrote:
|
Hello,
Not sure whether it could help since it is not directly related to ZF but, if you are using Zend Server perhaps it could lead you to a trail. Since we upgraded our dev env to: Ubuntu 13.04 PHP Version 5.4.16 Zend Server Version: 6.1.0 we also encounter segfaults when activating mod_ssl. The segfault happens on Apache at startup. Regards,
|
Hi Corentin, It sounds like you hit an Zend Server/Apache bug, rather than a php one. We are not using Zend Server, in fact we don't use mod_ssl either. We run 2 webservers with the Load balancer on AWS and the SSL decryption is handled in the Load Balancer. Giacomo On 4 September 2013 12:46, Corentin Larose - QAPA <[hidden email]> wrote:
|
In reply to this post by Marco Pivetta
After to Marco's suggestion we came to the conclusion that ZF2 2.2.0 works for us. From ZF2 2.2.1 on it segfaults within a few hours, or sometimes minutes.http://framework.zend.com/changelog/2.2.1 On 4 September 2013 11:12, Marco Pivetta <[hidden email]> wrote:
|
Administrator
|
On Thu, Sep 5, 2013 at 5:48 AM, Giacomo Orlandi <[hidden email]> wrote:
> After to Marco's suggestion we came to the conclusion that ZF2 2.2.0 works > for us. > From ZF2 2.2.1 on it segfaults within a few hours, or sometimes minutes. > > The changelog is quite large: > http://framework.zend.com/changelog/2.2.1 > Any more suggestion? For example we don't use Redis. > > One way to exclude more changes could be to deploy a specific commit of in > between 2.2.0 and 2.2.1, but would that be stable enough for production? We try to keep the master branch stable at all times. Occasionally we'll have bad commits, but it's rare. If you're able to triage and identify the commit that introduces the segfault, please report back so we can investigate. > On 4 September 2013 11:12, Marco Pivetta <[hidden email]> wrote: >> >> Yes please. Otherwise, the scope is still too broad. >> >> Marco Pivetta >> >> http://twitter.com/Ocramius >> >> http://ocramius.github.com/ >> >> >> On Wed, Sep 4, 2013 at 12:10 PM, Giacomo Orlandi <[hidden email]> >> wrote: >>> >>> We tried with ZF2 2.2.2 and 2.2.4 and we had the same issue. >>> Should we try also with 2.2.0 or 2.2.1? >>> >>> Thanks, >>> >>> Giacomo >>> >>> >>> On 4 September 2013 11:03, Marco Pivetta <[hidden email]> wrote: >>>> >>>> Did you try changing also the *MINOR* 2.2 version? That may help >>>> discovering what the failure actually is. >>>> >>>> Marco Pivetta >>>> >>>> http://twitter.com/Ocramius >>>> >>>> http://ocramius.github.com/ >>>> >>>> >>>> On Wed, Sep 4, 2013 at 11:55 AM, Giacomo Orlandi <[hidden email]> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> We started a ZF2 project a few months ago using ZF2 2.1.5 and php 5.4. >>>>> Everything was going well until we tried to upgrade ZF2 to version >>>>> 2.2.* >>>>> We first tried with version 2.2.2 and then recently 2.2.4. >>>>> The website runs fine for a few minutes, up to a few hours, and it >>>>> segfaults. >>>>> We currently run php 5.4.19 on Ubuntu Precise on Apache 2.2 and >>>>> mod_php. >>>>> >>>>> We made sure that we ONLY upgraded ZF2, and nothing else changed at the >>>>> same time. >>>>> The problem is that segfault doesn't happen immediately, it sometimes >>>>> takes a few hours, but once it happens it keeps segfaulting. >>>>> >>>>> We are also unable to reproduce the problem on our dev environment >>>>> despite using exactly the same software versions. >>>>> I know that a segfault problem is a bug in php, not ZF2, I'm asking >>>>> here to try to have a clue on how to reproduce the problem. >>>>> >>>>> I created a core dump, but I doubt it's going to be very useful without >>>>> a reliable way to reproduce the problem. >>>>> It looks like the segfault happens in zend_alloc.c. >>>>> >>>>> As it only happens after a while we thought it might be related to the >>>>> garbage collection. >>>>> We tried setting zend.enable_gc=0 and that seems to delay the problem, >>>>> but eventually it still happens. >>>>> Any clue of something that changed from 2.1.5 to 2.2.* that might cause >>>>> this issue? >>>>> >>>>> Thank you very much, >>>>> >>>>> Giacomo >>>>> >>>> >>> >> > -- Matthew Weier O'Phinney Project Lead | [hidden email] Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc |
Hi, Matthew we managed to identify the first "bad" hash: 6260787e4221d69dd1712aac69ff6b1d02b02ee7 Unfortunately that commit is a merge, therefore the diff with the previous one e662a0f319c290a3b7784b74080490549bb64732 is still quite big: We don't use Zend\Auth, nor Zend\Crypt, at least not directly.https://github.com/zendframework/zf2/compare/e662a0f319c290a3b7784b74080490549bb64732...6260787e4221d69dd1712aac69ff6b1d02b02ee7 So maybe it could be the changes in Zend\Db\Sql\Select or in Request.php... Giacomo On 5 September 2013 15:17, Matthew Weier O'Phinney <[hidden email]> wrote:
|
You should be able to 'git blame' up the merge parent until you find the true breaking commit. The parent
9cd25e1 is the master branch prior, b8abbb9 is the merged branch.On 9 September 2013 10:39, Giacomo Orlandi <[hidden email]> wrote:
|
On Mon, Sep 9, 2013 at 11:27 AM, Michael Gooden <[hidden email]> wrote:
|
Hi, We came to the conclusion that this is the "bad commit":https://github.com/zendframework/zf2/commit/6260787e4221d69dd1712aac69ff6b1d02b02ee7 It's basically introducing \Zend\Validator\Hostname to validate the hostname. We found this segfault bug, which sounds similar, but our coreDump doesn't seem to include any APC code, although we do use APC. https://bugs.php.net/bug.php?id=62587 Any idea? Thanks, Giacomo On 9 September 2013 12:11, Tomáš Fejfar <[hidden email]> wrote:
|
Btw this is our stack backtrace, but I personally cannot read much in it... #0 _zend_mm_free_int (heap=0x7f113e90b800, p=0x7f113eeb5e30) at /build/buildd/php5-5.4.19/Zend/zend_alloc.c:2100 #1 0x00007f11387be2f6 in _zval_dtor (zvalue=0x7f113eecc5b0) at /build/buildd/php5-5.4.19/Zend/zend_variables.h:35 #2 i_zval_ptr_dtor (zval_ptr=0x7f113eecc5b0) at /build/buildd/php5-5.4.19/Zend/zend_execute.h:87 #3 zend_leave_helper_SPEC (execute_data=0x7f113e9a1d80) at /build/buildd/php5-5.4.19/Zend/zend_vm_execute.h:468 #4 0x00007f11387efe6f in execute (op_array=0x7f113ee9d420) at /build/buildd/php5-5.4.19/Zend/zend_vm_execute.h:410 #5 0x00007f11387806c8 in zend_call_function (fci=0x7fffa16f3560, fci_cache=<optimized out>) at /build/buildd/php5-5.4.19/Zend/zend_execute_API.c:956 #6 0x00007f11386b486d in zif_call_user_func (ht=<optimized out>, return_value=0x7f113edde8f0, return_value_ptr=<optimized out>, this_ptr=<optimized out>, return_value_used=<optimized out>) at /build/buildd/php5-5.4.19/ext/standard/basic_functions.c:4729 #7 0x00007f1138836677 in zend_do_fcall_common_helper_SPEC (execute_data=<optimized out>) at /build/buildd/php5-5.4.19/Zend/zend_vm_execute.h:643 #8 0x00007f11387efe6f in execute (op_array=0x7f113ee4d7c8) at /build/buildd/php5-5.4.19/Zend/zend_vm_execute.h:410 #9 0x00007f11387806c8 in zend_call_function (fci=0x7fffa16f3850, fci_cache=<optimized out>) at /build/buildd/php5-5.4.19/Zend/zend_execute_API.c:956 #10 0x00007f11386b486d in zif_call_user_func (ht=<optimized out>, return_value=0x7f113ee54fb0, return_value_ptr=<optimized out>, this_ptr=<optimized out>, return_value_used=<optimized out>) at /build/buildd/php5-5.4.19/ext/standard/basic_functions.c:4729 #11 0x00007f1138836677 in zend_do_fcall_common_helper_SPEC (execute_data=<optimized out>) at /build/buildd/php5-5.4.19/Zend/zend_vm_execute.h:643 #12 0x00007f11387efe6f in execute (op_array=0x7f113ee4d7c8) at /build/buildd/php5-5.4.19/Zend/zend_vm_execute.h:410 #13 0x00007f113878f318 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /build/buildd/php5-5.4.19/Zend/zend.c:1315 #14 0x00007f113872e7b3 in php_execute_script (primary_file=0x7fffa16f5e00) at /build/buildd/php5-5.4.19/main/main.c:2497 #15 0x00007f11388384fd in php_handler (r=0x7f1137ea6cf0) at /build/buildd/php5-5.4.19/sapi/apache2handler/sapi_apache2.c:682 #16 0x00007f113d9ad508 in ap_run_handler () #17 0x00007f113d9ad97e in ap_invoke_handler () #18 0x00007f113d9bcbdc in ap_internal_redirect () #19 0x00007f11373c3635 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so #20 0x00007f113d9ad508 in ap_run_handler () #21 0x00007f113d9ad97e in ap_invoke_handler () #22 0x00007f113d9bd570 in ap_process_request () #23 0x00007f113d9ba398 in ?? () #24 0x00007f113d9b3fa8 in ap_run_process_connection () #25 0x00007f113d9c21d0 in ?? () #26 0x00007f113d9c293a in ?? () On 11 September 2013 16:54, Giacomo Orlandi <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |