Edit report at https://bugs.php.net/bug.php?id=79010&edit=1
ID: 79010
Comment by: pierre dot goiffon at combodo dot com
Reported by: stephen at sbillard dot org
Summary: __Call magic function is not invoked
Status: Open
Type: Bug
Package: Reproducible crash
Operating System: Windows
PHP Version: 7.4.1
Block user comment: N
Private report: N
New Comment:
Hello,
I'm running in something very similar to this bug in our application, but with the
__construct() method in a class hierarchy. Unfortunately I wasn't able to create a simple use
case to reproduce :(
The problem appears when running iTop (https://github.com/Combodo/iTop) setup with PHP 7.4 Windows,
xdebug installed and running, op cache disabled (same config as Stephen).
The setup instantiate what we call a datamodel : in short we have a custom ORM, each objects are
defined in a bunch of PHP files containing classes definitions extending iTop object root class
(DBObject). During the final phase, those files are called one by one to launch their Init() method,
which themselves are calling AttributeDefinition constructors for each objects attributes.
The setup crashes on the first Init() call, first AttributeDefinition child constructor call. Doing
a step by step using xdebug just shows that the execution stops. No error in the PHP error log.
In the AttributeDefinition classes hierarchy there were just a few children defining their
constructor. Adding __construct method to all children solves the problem.
Here is a the first call stack :
setup/ajax.dataloader.php
\WizStepSummary::AsyncAction // $sStep=='db-schema'
\ApplicationInstaller::ExecuteStep
\ApplicationInstaller::DoUpdateDBSchema
\RunTimeEnvironment::InitDataModel
\MetaModel::Startup
\MetaModel::LoadConfig
\MetaModel::InitClasse
\ModuleInstallation::Init
\MetaModel::Init_Params
\AttributeString::\__construct
\MetaModel::Init_AddAttribute
The AttributeDefinition classes hierarchy are located in core/attributedef.class.inc.php
(https://github.com/Combodo/iTop/blob/develop/core/attributedef.class.inc.php). Constructor methods
were added in children with https://github.com/Combodo/iTop/commit/e27eb7419ecffce7c86139aae41abd77a6d5cd39
As I said I did some tries to have a smaller code base to reproduce but with no luck. The repo is https://github.com/piRGoif/php79010 but does not show
the problem. Seems that iTop setup specific call stack make it all happens ?
Previous Comments:
------------------------------------------------------------------------
[2019-12-21 19:17:20] stephen at sbillard dot org
OP cache is disabled. I am not able to setup the backtrace environment. I doubt it matters, but I
did test to verify that the __toString() magic function works under the same conditions that
__call() fails.
Since I have a work-a-round using the __call() in the first child object to invoke parent::__call()
in the root object I think you can put this report on the back burner until someone with a better
chance of debugging it runs into the problem.
------------------------------------------------------------------------
[2019-12-21 11:16:44] cmb@php.net
If you're running with OPcache enabled, please also try with
OPcache disabled. Would that fix the problem?
See <https://bugs.php.net/bugs-generating-backtrace-win32.php>
on
how to generate a backtrace on Windows.
------------------------------------------------------------------------
[2019-12-21 01:41:15] stephen at sbillard dot org
I have Xdebug installed. It has not helped with the diagnostics. I have instrumented the code and
from what that tells me the __call() function is never invoked. Instead things just seem to stop.
I truly understand the problem of not being able to reproduce the problem. I've been there with
my users. I can reliably reproduce the issue with a simple test case running on my full application.
If there is any debugging options I should set I am quite willing to do so.
I can also provide you with the complete environment and test script it you wish.
------------------------------------------------------------------------
[2019-12-21 00:54:38] requinix@php.net
It'll be really hard to know what's wrong if we can't reproduce it.
Do you have Xdebug installed? If not, try with it and see what happens. Also make sure you have your
error reporting and logging settings set up properly for development and testing.
------------------------------------------------------------------------
[2019-12-21 00:26:17] stephen at sbillard dot org
Description:
------------
The magic method __call() appears fault under some conditions. I am unable to create a simple script
that reproduces the issue, though.
I am making a method call on an object where the method does not exist. The object on which the
method is invoked is a 4th level decedent from the object that contains the __call() definition.
When the method is invoked all output to the browser is terminated. In fact, I can inspect parts of
the page that are visible, but if I try to view the source (in Chrome) none is shown.
I am using Wampserver 32 bit version 3.2.2.2. I can switch to PHP version 7.3.13 and the code works.
To get the code to work on version 7.4.1 I have defined an __call() method in the first descendant
object that simply invokes parent::_call().
I have attempted to create a simple test case with these levels of object inheritance, but that
script does not fail. I regret that I cannot interpret the instructions for a gdb backtrace to the
Wampserver environment.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=79010&edit=1