Phalcon 1.3.x zend_mm_heap corrupted #2564
Comments
|
I also have this problem. |
|
Try to update PHP to 5.5 version |
$ php -v |
|
i have the same issue, php 5.5.xx + phalcon 1.3.2 + ZendOpCache + on OpenSuse 12.3 short extract of apache error log: |
|
We have the same problem with apache. Different pages, randomly. Sometimes we catch it on local machine. Php version 5.4.28, phalcon 1.3.2. It started maybe a month ago. |
|
Oh yeah, fantastic 😡 |
|
@swen100 @cvsguimaraes I found a possible workaround see this article: https://bugs.php.net/bug.php?id=65590 |
|
@tmatei Thank you for the link, but I have seen this already some time ago and it sadly has not helped me. |
|
I have the same problem, too, php5.5.12,phalcon1.3.1,nginx1.6.0. |
|
phalcon-1.3.2, php-5.5.14, opcache (7.0.3 and 7.0.4-dev) both same issue |
|
tried it out with newest version 1.3.3 and this issue still exists. |
|
Who can we get in touch with to see if they can fix this issue? |
|
Can someone provide a backtrace? git clone http://github.com/phalcon/cphalcon
git checkout 1.3.3
cd cphalcon/ext
sudo ./installcd /path/to/website/public
gdb php
(gdb) run index.php
(gdb) bt full |
|
this bug is very very annoying, but not easy reproducable. We have several hundred requests per minute and sometimes it occurs, but we can not figure out at which point or which request it happened... |
|
@phalcon The problem is that I don't think its reproducible from the command line. For my issues I was able to resolve this by turning off the opcache.fast_shutdown, but it was stated by @swen100 that did not fix his problem. One thing that I know for a fact is that the code was working fine in 1.2.x versions and something was introduced in 1.3.x branch since the very first version. To me it seems like something gets cached in opcache and its there for the next page request, which ends up crashing php. Is there another way to debug this? |
|
Same issue here. I solved the problem by disabling opcache, restarting apache and re-enabling opcache. |
|
Hi, |
|
It's correct, i restart apache again after re-enabling opcache :) |
|
We used jmeter to try to test this out, and very inconsistent. There was no way to repeat the problem. Out of say 1000 connections we would get only a small X number of failures. After over a month of this we finally had to downgrade. |
|
I use strace to attach a php-fpm process and get the following result: |
|
I am seeing This is a major problem as the file doesn't get read out before the crash and errors in the browser console. I tried increasing output buffering in PHP which didn't help and I've just turned output buffering off in PHP temporarily and will monitor to see if it improves things. |
|
And just had the crash again so disabling output buffering has not helped. So after 29minutes something has 'overflowed' and I'm now consistently getting @phalcon I tried generating a backtrace using the method you outlined above, however I have too many environment variables being set that I can't easily reproduce in the GDB command line. How else can I help to debug this? |
|
Hi everyone, i debugged and straced the app, and after many false positves, i found that my problem was some exit/die() putted somewhere in the Controller objects (usually after redirects). |
|
For me, it did not help. I removed all "die()"s, installed v.1.3.3, restarted apache... many zend_mm_heap_corruped... |
|
We downgraded to 1.3.1 and rewrited redirect methods (we used Location + exit). And now we have only several failed requests per day instead of thousands. |
|
@phalcon any idea? debugging with GDB it works, not-debugging wont work! How i can i deal with that? :) ...and now i'm having another behaviour running with gdb:
thx Mod: I'm trying to obtain something with valgrind |
|
@maxowar Without a backtrace or a script that successfully reproduces this issue, we are not able to fix this |
|
I got some memory errors from valgrind, unfortunately i wasnt able to connect with gdb (my own problems) Mod:
Mod: I remember that removing exit/die from controllers it works! The problem seems to be on the shutdown of some entities...like db maybe. |
|
@maxowar I've got a similar behavior with Xdebug; But I'm just guessing... |
|
One of my Phalcon projects randomly produces this behaviour with xdebug enabled - normally when trying to log a user in - I disable xdebug, login and then re-enable xdebug and the problem is solved. |
|
I tried to disable opcache, but zend_mm_heap is just replaced with a Segmentation fault. Removing xdebug didn't help either. I tried gdb on my public/index.php as phalcon said, and got this : I use PHP 5.6.0-1 |
|
We have also got the same problem with many pages. First we had Apache restarts with many pages that made calls to the database. To try to fix that we changed to using FastCGI PHP. But now we get this 'mod_fcgid: get overlap result error' for the same pages. This is running Windows 8.1, Apache 2.4.9, PHP 5.5.17-nts, Phalcon1.3.3, FastCGI We'll try to get a backtrace and post tomorrow. The problem is definitely repeatable and is currently a show-stopper for our application/site. There are probably a lot more people suffering this 'crash' but are commenting is various other places - it's quite an important thing that needs fixing. Otherwise there are likely to be many negative comments and reviews of this great framework. |
|
Just a note that I plan to test out the 2.0.0 branch to see if it still happens. We cannot consistently reproduce, but at least running jmeter for awhile does produce some errors. |
|
I've just compiled Phalcon again, from the git repo. I used the 1.3.4 remote branch this time. It works for me. |
|
I have tried it out too (version 1.3.4) and at this point: no zend_mm_heap errors. |
|
o.k., I don't know who made me happy, but here is a bottle of 🍻 for you! |
|
This is sounding good. Has anyone got a windows dll (64 or 32 bit) of 1.3.4 ? |
|
Found this issue via google. Not a phalcon user myself, but instead of disabling opcache altogether, setting opcache.fast_shutdown: 0 fixed the problem for me. |
|
I try with version 1.3.3 and it is work. |
|
I update to 1.3.3 and no more error! |
|
Nearly 3 weeks since 1.3.4 might have fixed the problem, but still no windows dll available on the download pages. Is there any timeframe for when there might be one? 1.3.3 definitely still has the problem for us. |
|
@VampireTiger windows dll in version 1.3.4 is out already. |
|
Fixed in 1.3.4 |
Hello.
Starting from the version of Phalcon 1.3.x we encountered php-fpm errors on the server that happened randomly, on random pages and didn't seem to be logical.
There were such entries in php-fpm logs:
We couldn't collect any further information about these errors.
First it happened on Debian 6, php 5.4
Then we moved to the server with Debian 7, php 5.5 but the errors were still happening.
Downgrade to the Phalcon 1.2.6 solved the problem.
We found a similar ticket that almost describes our problem #2516
Please fix it. Thanks.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: