Bug #79010 [Opn]: __Call magic function is not invoked

From: Date: Wed, 08 Jan 2020 09:13:57 +0000
Subject: Bug #79010 [Opn]: __Call magic function is not invoked
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-224769@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=79010&edit=1 ID: 79010 Updated by: requinix@php.net 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: @pierre: Can you try getting a backtrace? https://bugs.php.net/bugs-generating-backtrace-win32.php Previous Comments: ------------------------------------------------------------------------ [2020-01-08 09:08:29] pierre dot goiffon at combodo dot com 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 ? ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=79010 -- Edit this bug report at https://bugs.php.net/bug.php?id=79010&edit=1

« previous php.bugs (#224769) next »