Bug #79010 [Fbk->Asn]: __Call magic function is not invoked

Edit report at https://bugs.php.net/bug.php?id=79010&edit=1 ID: 79010 User updated by: stephen at sbillard dot org Reported by: stephen at sbillard dot org Summary: __Call magic function is not invoked -Status: Feedback +Status: Assigned Type: Bug Package: Reproducible crash Operating System: Windows PHP Version: 7.4.1 Assigned To: cmb Block user comment: N Private report: N New Comment: I have tested on PHP version 7.4.8 (I do not have access to 7.4.9 yet) and the __Call() problem no longer exists. Previous Comments: ------------------------------------------------------------------------ [2020-07-20 15:31:54] cmb@php.net > Here is below a step by step procedure to reproduce the problem. I have not been able to reproduce this with a PHP 7.4.9-dev debug build (i tried several times). Do you still experience this issue? ------------------------------------------------------------------------ [2020-01-10 17:02:22] pierre dot goiffon at combodo dot com Woops I forgot to mention that running the MS diag tool with the rule activated, and with httpd running as usual in my wamp, there were nothing generated to analyze :/ ------------------------------------------------------------------------ [2020-01-10 16:49:32] pierre dot goiffon at combodo dot com Hello, I'm really sorry, I wasn't able to create a backtrace :( One of the wiki step is to start Apache with the -X command line option : I'm running Apache + MySQL using the WAMP package (http://www.wampserver.com/), and I didn't find how to add a specific command line argument :/ I tried : * changing the command line used in the "wampapache64" service (from {"c:\Dev\wamp64\bin\apache\apache2.4.27\bin\httpd.exe" -k runservice} to {"c:\Dev\wamp64\bin\apache\apache2.4.27\bin\httpd.exe" -X -k runservice}) : no luck the server does not start anymore * shutdown the httpd launched by wamp and launch it manually : I get an error in a dialog when starting about a missing entry point in php_curl.dll, then some error message. However the first query is executed ok, but during the second one the server crashes In the mean time a colleague tested the setup in PHP 7.4.1 on Arch Linux : no crash or error. Here is below a step by step procedure to reproduce the problem. You will need Apache and also a connection to a running MySQL server. 1. get the content of https://github.com/Combodo/iTop/tree/feature/php79010 2. copy this to your apache dir 3. access the dir using the browser => you'll get redirected to the iTop setup (title "Welcome to iTop version 2.7.0-dev") 4. click next => "Install or Upgrade choice" 5. choose "Install a new iTop", click next => "License Agreement" 6. check the checkbox, click next => "Database Configuration" 7. fill the fields to connect to your MySQL server, choose a db (won't be created, this is done during the final phase but the code crashes before), click next => "Administrator Account" 8. fill the mandatory fields, click next, click ok on the prompt about impact analysis => "Miscellaneous Parameters" 9. click next => "Configuration Management options" 10. click next => "Service Management options" 11. click next => "Tickets Management options" 12. click next => "Change Management options" 13. click next => "Additional ITIL tickets" 14. click next => "Ready to install" ⚠ this is the final step before the crash 15. click next => some AJAX calls are made, you will get the crash during the 4th call at 40%. In the browser you'll just see a stall and an "undefined" string in red below the buttons ------------------------------------------------------------------------ [2020-01-08 09:13:57] requinix@php.net @pierre: Can you try getting a backtrace? https://bugs.php.net/bugs-generating-backtrace-win32.php ------------------------------------------------------------------------ [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 ? ------------------------------------------------------------------------ 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