php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60816 spl_autoload_register fails with __call magic
Submitted: 2012-01-20 06:22 UTC Modified: 2017-12-06 22:53 UTC
From: dan dot lugg at gmail dot com Assigned: nikic (profile)
Status: Closed Package: SPL related
PHP Version: 5.3.9 OS: Windows 7x64
Private report: No CVE-ID: None
 [2012-01-20 06:22 UTC] dan dot lugg at gmail dot com
Description:
------------
When registering a callback object/method pair to spl_autoload_register(), if 
the 
method is not defined, though the object class has defined __call() magic, the 
method will not be called during an autoload attempt.

In a larger project, I found that the PHP executable was crashing out 
altogether, 
appending no output to the logs, and offering minimal information. When I 
isolated 
what I suspected to be the problem, it was in fact the 
spl_autoload_register()/__call() combination. In isolation, it did not crash out 
spectacularly as in my project, however it still failed.

While I marked this 5.3.9, these failures have been observed on 5.3.8, 5.3.9, 
and 
5.4.0.RC3.

While this is a bit of an edge case, I doubt that this is expected or acceptable 
behaviour, and have not been able to find mention of this elsewhere.

Test script:
---------------
<?php

    class Loader
    {
        public function __call($name, $arguments)
        {
            var_dump(get_defined_vars());
        }
    }
	
    spl_autoload_register(array(new Loader(), 'load_class'));
    $foo = new Bar();

Expected result:
----------------
    array(2) {
      ["name"]=>
      string(10) "load_class"
      ["arguments"]=>
      array(1) {
        [0]=>
        string(3) "Bar"
      }
    }
    Fatal error: Class 'Bar' not found in - on line 12

Actual result:
--------------
    Fatal error: Class 'Bar' not found in - on line 12


As you can see, while this test script made no attempt to actually load the class, 
it should at least be dumping the array before failing, as in the expected output.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-01-20 06:57 UTC] levim@php.net
This works on viper-7:  http://viper-7.com/KPlQLa
 [2012-01-20 12:53 UTC] dan dot lugg at gmail dot com
Fellow programmers online have confirmed this may be a non-issue, however all 
cases where the problem did not crop up were on *nix flavours; perhaps it is an OS 
specific/related issue.
 [2017-12-06 22:53 UTC] nikic@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: nikic
 [2017-12-06 22:53 UTC] nikic@php.net
Here's a working reproducer: https://3v4l.org/AecvW

This is a duplicate of bug #73896, which has been fixed with https://github.com/php/php-src/commit/4f1b24d97447434973a06bdc70fc1670de17bd80 in 7.0.16, 7.1.2.
 
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Wed Dec 12 16:01:26 2018 UTC