Bug #67807 [Opn->Fbk]: Object passed by reference becomes a string
| From: | dmitry@php.net | Date: | Thu, 14 Jul 2016 11:26:04 +0000 |
| Subject: | Bug #67807 [Opn->Fbk]: Object passed by reference becomes a string | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-202314@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=67807&edit=1
ID: 67807
Updated by: dmitry@php.net
Reported by: atlantisnova at gmail dot com
Summary: Object passed by reference becomes a string
-Status: Open
+Status: Feedback
Type: Bug
Package: Scripting Engine problem
Operating System: Debian Linux
PHP Version: 5.4.4
Block user comment: N
Private report: N
New Comment:
I can't reproduce this with PHP-5.3 and above.
Previous Comments:
------------------------------------------------------------------------
[2014-08-12 01:30:40] requinix@php.net
Related To: Bug #67824
------------------------------------------------------------------------
[2014-08-08 22:01:19] atlantisnova at gmail dot com
In case it's helpful for anyone else with similar issues: we discovered this problem because
objects seemed to "disappear" between calls, eg:
$my_obj->do_thing1() || $my_obj->do_thing2();
$my_obj works fine when do_thing1 is called, but throws a "Call to a member function
do_thing2() on a non-object" fatal error on do_thing2. This is because do_thing1 called an
$other_object->other_function($this), which accepted that param by reference (public function
other_function(&$obj)). Any notice (undefined variable, trigger_error, etc) in other_function
caused $obj/$this/$my_obj to be rewritten as 'MyClass' due to our custom error handler
(which was trying to stringify/truncate the stack trace for logging purposes), and hence the call to
do_thing2() failed (since we were calling it on a string).
------------------------------------------------------------------------
[2014-08-08 20:50:49] requinix@php.net
Yeah, that certainly explains it.
So what to do with this? The most similar report I can find is bug #48847 where @stas says that
modifying data in the backtrace is "definitely not a supported functionality", but
I'm not sure whether to interpret that as meaning undesired behavior (a bug) or undefined
behavior (not a bug).
------------------------------------------------------------------------
[2014-08-08 20:06:07] atlantisnova at gmail dot com
Why yes, yes I am... sorry it's done in an auto_prepend and I forgot about it. And yes, that
was the problem:
http://3v4l.org/FUqWS (includes the original comment explaining
why we were converting to classname)
Looks like the objects returned by debug_backtrace() are true references, and hence when we were
looping through to truncate the log message the object got wiped.
So I'm happy because it's an easy fix - feel free to close this ticket unless you feel
that debug_backtrace should return object identifiers rather than aliases... looks like it already
functions that way in hhvm.
Either way, thanks so much for your time!
------------------------------------------------------------------------
[2014-08-08 18:28:40] requinix@php.net
You wouldn't happen to be using a custom error handler, right? If you are, what's the
code?
------------------------------------------------------------------------
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=67807
--
Edit this bug report at https://bugs.php.net/bug.php?id=67807&edit=1