Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68974
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain newrelic.com designates 209.85.215.53 as permitted sender)
MIME-Version: 1.0
Date: Mon, 9 Sep 2013 10:25:13 -0700
Message-ID: <CAHnxEyR8b1b=cbbDxf3Tn-K-7C+R7v9UDK+NOA=6P5fKvHVmfg@mail.gmail.com>
To: internals@lists.php.net
Cc: yohgaki@php.net
Content-Type: multipart/alternative; boundary=001a1133659ccde2f604e5f6abd4
Subject: segfaulting in php5.5 core when doing function wrapping
From: rrh@newrelic.com (Robert Henry)

--001a1133659ccde2f604e5f6abd4
Content-Type: text/plain; charset=ISO-8859-1

I have a PHP extension that wraps or replaces function calls.  This
extension has worked successfully with minimal changes between php versions
from PHP 5.1 through PHP 5.4.  However, my attempts to port this extension
to PHP 5.5 have failed in one case, which makes we wonder about my other
successes with PHP 5.5.

I have figured out that in order to get access to the incoming actual
parameters for a hooked function I need to indirect through
->prev_execute_data iff the arguments pointer on the topmost frame is null.

Here's the scenario where I segfault:

I rebind zend_execute_ex to point to my executor.  For most code paths my
executor does:
(a) gathers some profiling data;
(b) may call 0 or more times to other php functions using the
call_user_function_ex entry point into zend;
(c) turns around and calls execute_ex (zend_execute_data *ed), with the
same value of ed that my executor was given and so apparently correctly
executes the original function in what I presume is the correct evaluation
context.

However, if I do not do step (c) to execute the intended function, then
shortly after my executor returns I get a segfault in
zend_vm_stack_get_arg_ex (zend_execute.h line 320 from php 5.5.3), called
by zend_vm_stack_get_arg, called by ZEND_RECV_SPEC_HANDLER.  The location
of the segfault has been seen to move around, and, for example, has been
observed to happen when the number of local slots to clear in a
clear_multiple is the bogus value 0x5a5a5a5a (which says, obviously,
there's memory corruption).

The discussions here
http://www.php.net/manual/en/migration55.internals.phpdo not provide
enough insight as to the changes in zend and how the
extension authors need to adjust for these changes.

Is there another working extension that does similar things that I can
study, or other guidelines to consult?

I note that Julienn Salleyron reported similar issues with his AOP work,
but that work contains a lot of code very specific to the implementation of
zend itself, and so from my position looks to be "too complex".

-- 
Robert Henry, New Relic

--001a1133659ccde2f604e5f6abd4--