This one:
*** glibc detected *** /usr/local/bin/php-cgi: double free or
corruption (out): 0x00007f9d6ce2c080 ***
======= Backtrace: =========
/lib/libc.so.6(+0x77806)[0x7f9d679be806]
/lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3]
/usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d]
/usr/local/bin/php-cgi(zend_hash_clean+0x73)[0x75f393]
/usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f9d65d1e460]
Is pretty nasty and we're getting it on lots of servers. #61238 says
it's a known and fixed issue, but we still have it with a fresh build
of PHP 5.4.4 and apc installed immediately thereafter via pecl.
Is this fix actually released yet?
Thanks.
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
This one:
*** glibc detected *** /usr/local/bin/php-cgi: double free or
corruption (out): 0x00007f9d6ce2c080 ***
======= Backtrace: =========
/lib/libc.so.6(+0x77806)[0x7f9d679be806]
/lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3]
/usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d]
/usr/local/bin/php-cgi(zend_hash_clean+0x73)[0x75f393]
/usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f9d65d1e460]Is pretty nasty and we're getting it on lots of servers. #61238 says
it's a known and fixed issue, but we still have it with a fresh build
of PHP 5.4.4 and apc installed immediately thereafter via pecl.Is this fix actually released yet?
Like I said in the bug report, install APC from SVN. We have a few more
things to fix before we are ready for an APC release. Unfortunately
there are a lot fewer people working on APC than other parts of PHP. It
is extremely difficult and not very sexy work. And with that enticing
description, if anyone reading this would like to pitch in and help fix
the remaining small PHP 5.4 edge cases in APC, it would be much appreciated.
-Rasmus
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main "if these fail, it's not ready" test suite.
But I suppose that's just administering beatings until morale improves
(:
This one:
*** glibc detected *** /usr/local/bin/php-cgi: double free or
corruption (out): 0x00007f9d6ce2c080 ***
======= Backtrace: =========
/lib/libc.so.6(+0x77806)[0x7f9d679be806]
/lib/libc.so.6(cfree+0x73)[0x7f9d679c50d3]
/usr/local/bin/php-cgi(destroy_zend_class+0x23d)[0x749f5d]
/usr/local/bin/php-cgi(zend_hash_clean+0x73)[0x75f393]
/usr/local/lib/php/extensions/no-debug-non-zts-20100525/apc.so(apc_interned_strings_shutdown+0x20)[0x7f9d65d1e460]Is pretty nasty and we're getting it on lots of servers. #61238 says
it's a known and fixed issue, but we still have it with a fresh build
of PHP 5.4.4 and apc installed immediately thereafter via pecl.Is this fix actually released yet?
Like I said in the bug report, install APC from SVN. We have a few more
things to fix before we are ready for an APC release. Unfortunately
there are a lot fewer people working on APC than other parts of PHP. It
is extremely difficult and not very sexy work. And with that enticing
description, if anyone reading this would like to pitch in and help fix
the remaining small PHP 5.4 edge cases in APC, it would be much appreciated.-Rasmus
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
hi Tom,
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main "if these fail, it's not ready" test suite.
But I suppose that's just administering beatings until morale improves
(:
That's why latest APC releases are beta and not stable.
Interned string and a couple of other things need some more work to get fixed.
One way to speed up things is to provide small reproduce cases for
bugs, so we can fix them quicker.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
There are alternative opcode cachers besides APC. For example xcache, for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that hard to keep up with the changes in the PHP, maybe that is
not the case now.
But looking at the xcache and using it in production for 5-6 years I see
that something is true in the previous statement, because when new version
is out - xcache is always up to date, witch can't be said about the APC.
Just say'n.
2012/7/3 Tom Boutell tom@punkave.com
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main "if these fail, it's not ready" test suite.
But I suppose that's just administering beatings until morale improves
(:
hi,
There are alternative opcode cachers besides APC. For example xcache, for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that hard to keep up with the changes in the PHP, maybe that is
not the case now.
It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.
Other developers may disagree but it makes very hard to maintain APC.
Cheers,
2012/7/3 Tom Boutell tom@punkave.com
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main "if these fail, it's not ready" test suite.
But I suppose that's just administering beatings until morale improves
(:
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre,
It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
Perhaps that indicates it's time to pull the core of APC into php's
core... Just the core, not all of those other features. Then the APC
extension can still exist for those additional legacy features, but
the core functionality can be shipped with PHP itself.
I know there was talk about adding that to php6 by default, perhaps
5.5 (or 5.6) could benefit from it...
Thoughts?
Anthony
It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
Perhaps that indicates it's time to pull the core of APC into php's
core... Just the core, not all of those other features. Then the APC
extension can still exist for those additional legacy features, but
the core functionality can be shipped with PHP itself.I know there was talk about adding that to php6 by default, perhaps
5.5 (or 5.6) could benefit from it...Thoughts?
Would that provide an sufficent improvement over the alternatives to justify forcing it's general use. I still prefer eaccellerator from a performance point of view ... And others do prefer the alternatives. Almost worth asking which Is prefered.
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
[Pierre said:]
It is still the case.I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
Perhaps that indicates it's time to pull the core of APC into php's core...
Just the core, not all of those other features. Then the APC extension can
still exist for those additional legacy features, but the core
functionality can be shipped with PHP itself.I know there was talk about adding that to php6 by default, perhaps
5.5 (or 5.6) could benefit from it...
Sorry for reviving a long-dead thread:
I absolutely concur that the core of APC should get pulled into subsequent versions of PHP...then Wincache can go away. ;)
Thx!
--E.
hi!
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
[Pierre said:]
It is still the case.I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
Perhaps that indicates it's time to pull the core of APC into php's core...
Just the core, not all of those other features. Then the APC extension can
still exist for those additional legacy features, but the core
functionality can be shipped with PHP itself.I know there was talk about adding that to php6 by default, perhaps
5.5 (or 5.6) could benefit from it...Sorry for reviving a long-dead thread:
I absolutely concur that the core of APC should get pulled into subsequent versions of PHP...then Wincache can go away. ;)
Any help would be appreciated. What is very in wincache is that many
APC options are default in wincache. The filecache could be extracted
as well and made a standalone ext (that's easier to maintain and need
separate cache :). That's something we discuss back then when the 1st
versions of wincache were being implemented.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
The ability to store your own data in the APC cache is a feature that
does get used a lot in the Symfony framework world because of the
availability of the sfAPCCache and whatever its Symfony 2 equivalent
is. It's popular with folks who haven't felt the need to set up Redis
or some other external cache yet. I'm not sure whether this is
something you consider a "legacy feature."
hi,
There are alternative opcode cachers besides APC. For example xcache, for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that hard to keep up with the changes in the PHP, maybe that is
not the case now.It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
Cheers,
2012/7/3 Tom Boutell tom@punkave.com
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main "if these fail, it's not ready" test suite.
But I suppose that's just administering beatings until morale improves
(:--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Just to be clear - all 3 major opcode cachers i know (zend optimizer
excluded - have no idea what he has) have that shared memory cache with
almost identical API. Some have extended functionality (xcache has
xcache_isset(), haven't seen that in others, but have to confess i haven't
been looking for some time now), so they are easily swappable.
03.07.2012 15:54 пользователь "Tom Boutell" tom@punkave.com написал:
The ability to store your own data in the APC cache is a feature that
does get used a lot in the Symfony framework world because of the
availability of the sfAPCCache and whatever its Symfony 2 equivalent
is. It's popular with folks who haven't felt the need to set up Redis
or some other external cache yet. I'm not sure whether this is
something you consider a "legacy feature."hi,
On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:There are alternative opcode cachers besides APC. For example xcache,
for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that hard to keep up with the changes in the PHP, maybe that
is
not the case now.It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
Cheers,
2012/7/3 Tom Boutell tom@punkave.com
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main "if these fail, it's not ready" test suite.
But I suppose that's just administering beatings until morale improves
(:--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
There are really just two big features in APC. The opcode caching and
the user-cache that sits on top of the same shared memory segment used
by the opcode cache. Everything else are just little tweaks that amount
to very little code. The biggest cleanup we would get moving it to core
would be the ability to drop all the #ifdef checks for the different
engine versions since we would obviously only need to support the
current one.
-Rasmus
hi Rasmus,
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
There are really just two big features in APC. The opcode caching and
the user-cache that sits on top of the same shared memory segment used
by the opcode cache.
Right, I wold like to split them tho'. To have two independent memory
for opcodes and user cache.
Everything else are just little tweaks that amount
to very little code.
Maintenance complexity is not necessary related to the amount of code
but the amount of cases to test. These cases also make very hard for
our users to understand APC and how it behaves (the stat=0 being the
easiest one to understand but causing most issues, for example).
That's where eAccelerator or xCache do way better, if it works, it
simply works, no magic option or other confusing (for the users)
options.
The biggest cleanup we would get moving it to core
would be the ability to drop all the #ifdef checks for the different
engine versions since we would obviously only need to support the
current one.
We will still have to support current supported versions via PECL.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be significantly slower in production for those who
know what they're doing, yes?
(I haven't actually tried the stat=0 trick myself yet and don't have
performance numbers on its impact. I really ought to though, since
hitting an API URL that clears the APC cache as part of deployment
should be pretty easy.)
hi Rasmus,
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
There are really just two big features in APC. The opcode caching and
the user-cache that sits on top of the same shared memory segment used
by the opcode cache.Right, I wold like to split them tho'. To have two independent memory
for opcodes and user cache.Everything else are just little tweaks that amount
to very little code.Maintenance complexity is not necessary related to the amount of code
but the amount of cases to test. These cases also make very hard for
our users to understand APC and how it behaves (the stat=0 being the
easiest one to understand but causing most issues, for example).That's where eAccelerator or xCache do way better, if it works, it
simply works, no magic option or other confusing (for the users)
options.The biggest cleanup we would get moving it to core
would be the ability to drop all the #ifdef checks for the different
engine versions since we would obviously only need to support the
current one.We will still have to support current supported versions via PECL.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be significantly slower in production for those who
know what they're doing, yes?
Depends on your code. For people who write code that needs to include
hundreds, or even thousands of files per request, yes, stat=0 is a big
feature. For saner code it is much less important.
-Rasmus
Heh... passing a little judgment there on the design of frameworks,
ORMs, etc. are we?
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be significantly slower in production for those who
know what they're doing, yes?Depends on your code. For people who write code that needs to include
hundreds, or even thousands of files per request, yes, stat=0 is a big
feature. For saner code it is much less important.-Rasmus
--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com
hi Tom,
Hmm, but the stat=0 optimization is a major one; a cache that didn't
offer it would be significantly slower in production for those who
know what they're doing, yes?
yes and no, really depends on the codes.
However my point was not really about the importance of a given
feature but its limitation or drawbacks. stat=0 being the one causing
most troubles to lambda users (relative paths usage and the likes).
That could be done in a more transparent way, without needing an
option to enable this optimization (wincache and other does it). So
could be other options, limit them to the critical ones (size of the
cache and the likes) and leave the rest to our choices, filling the
mass needs before the needs of the 1%.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
One one side it's good to know i'm not wrong, on the other hand it's sad in
this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone complaining about xcache. And
heard many complains about APC.
03.07.2012 15:17 пользователь "Pierre Joye" pierre.php@gmail.com написал:
hi,
On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:There are alternative opcode cachers besides APC. For example xcache, for
me, just works when APC is still catching up.
I remember someone writing about APC that it is overly compex internally
and due to that hard to keep up with the changes in the PHP, maybe that
is
not the case now.It is still the case.
I for one would like to kill all the legacy features or too specific
features which are really unusable by any common developers.Other developers may disagree but it makes very hard to maintain APC.
Cheers,
2012/7/3 Tom Boutell tom@punkave.com
Given the impracticality of using PHP without APC, it would be nice if
it were part of the main "if these fail, it's not ready" test suite.
But I suppose that's just administering beatings until morale improves
(:--
Pierre@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
One one side it's good to know i'm not wrong, on the other hand it's sad
in this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone complaining about xcache. And
heard many complains about APC.
Well, that is simply not true. We get a lot of, "I tried xcache, but it
didn't work, so now I am trying APC" type of messages and bug reports in
the APC world.
-Rasmus
Could be, xcache is definetly dummer in features and it is its feature. I
guess it helps it to keep up with releases. I will investigate this today,
maybe get some interesting results worth to share here.
03.07.2012 16:54 пользователь "Rasmus Lerdorf" rasmus@lerdorf.com написал:
One one side it's good to know i'm not wrong, on the other hand it's sad
in this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone complaining about xcache. And
heard many complains about APC.Well, that is simply not true. We get a lot of, "I tried xcache, but it
didn't work, so now I am trying APC" type of messages and bug reports in
the APC world.-Rasmus
One one side it's good to know i'm not wrong, on the other hand it's sad in
this case.
Sure about one thing - xcache is worth looking at and may be a better
choise than APC and has better potential.
One thing sure - I haven't heard anyone complaining about xcache. And
heard many complains about APC.
XCache just crashed for me: http://xcache.lighttpd.net/ticket/240
No reproduce case and no idea how to make one - there are megabytes of code involved.
We've been using APC for a year and a half after that and I was pretty much happy with it, except it crashed ~once a day with totally obscure backtrace.
Not much of a problem, but kind of annoying and APC sources gave me headaches, so I revived eAccelerator instead and made it work with 5.3.
With EA there was absolutely no difference in performance comparing to APC and the crashes are gone now.
But now I'll have to make EA work with 5.4 and it's interned string hell.., which is quite different story.
You might want to look at my EA fork, though: https://github.com/tony2001/eaccelerator/tree/alt
--
Wbr,
Antony Dovgal
http://pinba.org - realtime profiling for PHP