Tom Boutell | 3 Jul 16:13 2012

[PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)

Rasmus Lerdorf | 3 Jul 16:20 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

On 07/03/2012 07:13 AM, Tom Boutell wrote:
> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Tom Boutell | 3 Jul 16:49 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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
(:

On Tue, Jul 3, 2012 at 10:20 AM, Rasmus Lerdorf <rasmus <at> lerdorf.com> wrote:
> On 07/03/2012 07:13 AM, Tom Boutell wrote:
>> 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.
(Continue reading)

Pierre Joye | 3 Jul 17:02 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

hi Tom,

On Tue, Jul 3, 2012 at 4:49 PM, Tom Boutell <tom <at> punkave.com> wrote:
> 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

 <at> pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Arvids Godjuks | 3 Jul 17:12 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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 <at> 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 Joye | 3 Jul 17:17 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

hi,

On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks <arvids.godjuks <at> 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 <at> 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

 <at> pierrejoye | http://blog.thepimp.net | http://www.libgd.org

(Continue reading)

Anthony Ferrara | 3 Jul 17:26 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Lester Caine | 3 Jul 17:38 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

> > 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.
Eric Stenson | 24 Oct 22:47 2012
Picon

RE: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

> From: Anthony Ferrara [mailto:ircmaxell <at> 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.

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)

Pierre Joye | 25 Oct 09:04 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

hi!

On Wed, Oct 24, 2012 at 10:47 PM, Eric Stenson <ericsten <at> microsoft.com> wrote:
>> From: Anthony Ferrara [mailto:ircmaxell <at> 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
(Continue reading)

Tom Boutell | 3 Jul 17:53 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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."

On Tue, Jul 3, 2012 at 11:17 AM, Pierre Joye <pierre.php <at> gmail.com> wrote:
> hi,
>
> On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks <arvids.godjuks <at> 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 <at> 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.
(Continue reading)

Arvids Godjuks | 3 Jul 18:54 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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 <at> 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."
>
> On Tue, Jul 3, 2012 at 11:17 AM, Pierre Joye <pierre.php <at> gmail.com> wrote:
> > hi,
> >
> > On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks <arvids.godjuks <at> 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
(Continue reading)

Rasmus Lerdorf | 3 Jul 18:35 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

On 07/03/2012 08:17 AM, Pierre Joye wrote:
> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Pierre Joye | 4 Jul 11:55 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

hi Rasmus,

On Tue, Jul 3, 2012 at 6:35 PM, Rasmus Lerdorf <rasmus <at> lerdorf.com> wrote:
> On 07/03/2012 08:17 AM, Pierre Joye wrote:
>> 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
(Continue reading)

Tom Boutell | 4 Jul 16:37 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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.)

On Wed, Jul 4, 2012 at 5:55 AM, Pierre Joye <pierre.php <at> gmail.com> wrote:
> hi Rasmus,
>
> On Tue, Jul 3, 2012 at 6:35 PM, Rasmus Lerdorf <rasmus <at> lerdorf.com> wrote:
>> On 07/03/2012 08:17 AM, Pierre Joye wrote:
>>> 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
(Continue reading)

Rasmus Lerdorf | 4 Jul 16:41 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

On 07/04/2012 07:37 AM, Tom Boutell wrote:
> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Tom Boutell | 4 Jul 17:02 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

Heh... passing a little judgment there on the design of frameworks,
ORMs, etc. are we?

On Wed, Jul 4, 2012 at 10:41 AM, Rasmus Lerdorf <rasmus <at> lerdorf.com> wrote:
> On 07/04/2012 07:37 AM, Tom Boutell wrote:
>> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Pierre Joye | 5 Jul 12:10 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

hi Tom,

On Wed, Jul 4, 2012 at 4:37 PM, Tom Boutell <tom <at> punkave.com> wrote:
> 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

 <at> pierrejoye | http://blog.thepimp.net | http://www.libgd.org

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)

Arvids Godjuks | 3 Jul 18:49 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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 <at> gmail.com> написал:

> hi,
>
> On Tue, Jul 3, 2012 at 5:12 PM, Arvids Godjuks <arvids.godjuks <at> 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 <at> punkave.com>
> >
(Continue reading)

Rasmus Lerdorf | 3 Jul 18:54 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

On 07/03/2012 09:49 AM, Arvids Godjuks wrote:
> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Arvids Godjuks | 3 Jul 18:57 2012
Picon

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

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 <at> lerdorf.com> написал:

> On 07/03/2012 09:49 AM, Arvids Godjuks wrote:
> > 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
>
>
>
Antony Dovgal | 4 Jul 12:12 2012

Re: [PHP-DEV] Is the fix for #61238 in PHP 5.4.4 & pecl yet?

On 2012-07-03 20:49, Arvids Godjuks wrote:
> 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

--

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(Continue reading)


Gmane