|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79010 __Call magic function is not invoked
Submitted: 2019-12-21 00:26 UTC Modified: 2020-07-20 21:16 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: stephen at sbillard dot org Assigned: cmb (profile)
Status: Closed Package: Reproducible crash
PHP Version: 7.4.1 OS: Windows
Private report: No CVE-ID: None
 [2019-12-21 00:26 UTC] stephen at sbillard dot org
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 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.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-12-21 00:54 UTC]
-Status: Open +Status: Feedback
 [2019-12-21 00:54 UTC]
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 01:41 UTC] stephen at sbillard dot org
-Status: Feedback +Status: Open
 [2019-12-21 01:41 UTC] 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 11:16 UTC]
-Status: Open +Status: Feedback
 [2019-12-21 11:16 UTC]
If you're running with OPcache enabled, please also try with
OPcache disabled.  Would that fix the problem?

See <> on
how to generate a backtrace on Windows.
 [2019-12-21 19:17 UTC] stephen at sbillard dot org
-Status: Feedback +Status: Open
 [2019-12-21 19:17 UTC] 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.
 [2020-01-08 09:08 UTC] pierre dot goiffon at combodo dot com

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 ( 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 :

  \WizStepSummary::AsyncAction // $sStep=='db-schema'

The AttributeDefinition classes hierarchy are located in core/ ( Constructor methods were added in children with

As I said I did some tries to have a smaller code base to reproduce but with no luck. The repo is but does not show the problem. Seems that iTop setup specific call stack make it all happens ?
 [2020-01-08 09:13 UTC]
@pierre: Can you try getting a backtrace?
 [2020-01-10 16:49 UTC] pierre dot goiffon at combodo dot com

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 (, 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
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-10 17:02 UTC] 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-07-20 15:31 UTC]
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2020-07-20 15:31 UTC]
> 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
 [2020-07-20 21:04 UTC] stephen at sbillard dot org
-Status: Feedback +Status: Assigned
 [2020-07-20 21:04 UTC] stephen at sbillard dot org
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.
 [2020-07-20 21:16 UTC]
-Status: Assigned +Status: Closed
 [2020-07-20 21:16 UTC]
Thanks for checking, Stephen!

I only realized now that the issue reported by Pierre may have a
completely different cause, so it is better reported as separate
ticket, if still relevant.
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Tue Nov 29 13:05:54 2022 UTC