Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67708
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51BB6287.1020200@lerdorf.com>
References: <CAAyV7nE11wPTj=2vgSaNSF0tMTu6cpHSwoA_P7DLWSKt5g_YZg@mail.gmail.com>
	<51BB6287.1020200@lerdorf.com>
Date: Fri, 14 Jun 2013 14:47:38 -0400
Message-ID: <CAAyV7nGv8CUJzD-HcZHE2vUmofveqoFackVTdFq4CPXq1ZuPUw@mail.gmail.com>
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b417e195b2f6204df21ae3f
Subject: Re: [PHP-DEV] Zend GC Recursion Elimination
From: ircmaxell@gmail.com (Anthony Ferrara)

--047d7b417e195b2f6204df21ae3f
Content-Type: text/plain; charset=ISO-8859-1

Rasmus,


On Fri, Jun 14, 2013 at 2:35 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> On 06/14/2013 11:04 AM, Anthony Ferrara wrote:
> > When you run that on current master, you get a segfault stemming from the
> > zval_mark_grey() GC function.
>
> This segfault, or at least a segfault in zval_mark_grey(), has been
> reported a couple of times:
>
> https://bugs.php.net/64868
> https://bugs.php.net/64827
> https://bugs.php.net/61968


A quick look at those bugs appears to be a different cause. The backtrace
is VERY different from the segfault I got:

#0  0x0000000000587122 in zval_mark_grey (pz=0x7ffff1a7ce38) at
/home/ircmaxell/php-src2/Zend/zend_gc.c:374
#1  0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at
/home/ircmaxell/php-src2/Zend/zend_gc.c:432
#2  0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at
/home/ircmaxell/php-src2/Zend/zend_gc.c:432
#3  0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at
/home/ircmaxell/php-src2/Zend/zend_gc.c:432
**SNIP**
#196320 0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at
/home/ircmaxell/php-src2/Zend/zend_gc.c:432
#196321 0x0000000000587255 in zval_mark_grey (pz=<value optimized out>) at
/home/ircmaxell/php-src2/Zend/zend_gc.c:432
#196322 0x0000000000588105 in gc_mark_roots () at
/home/ircmaxell/php-src2/Zend/zend_gc.c:501
#196323 gc_collect_cycles () at /home/ircmaxell/php-src2/Zend/zend_gc.c:795
#196324 0x0000000000588359 in gc_zval_possible_root (zv=<value optimized
out>) at /home/ircmaxell/php-src2/Zend/zend_gc.c:166
...

So this is due to DEEP recursion (but not infinite) in zval_mark_grey,
where those 3 bugs (at least the two with backtraces) appear to be more
illegal memory access as opposed to unbound recursion... At least on the
surface...


> > So not a huge win overall, but can be significant in cases...
> >
> > What do you think? Is this worth pursuing further? is there a case I'm
> > missing, or some other reason we shouldn't do this?
>
> Since the reduced stack usage is likely to reduce the chances of hitting
> this segfault, which if it is the same one as in the bug reports, it is
> happening in the wild, then it is very much worthwhile to pursue this.
>
>
Well, again, this segfault is an extreme edge-case. I'm not sure if it will
work, but I will tag into one of those tickets, and see if this refactor
does indeed clean it up (or not)...

Thanks

Anthony

--047d7b417e195b2f6204df21ae3f--