Bug #67807 [Opn->Fbk]: Object passed by reference becomes a string

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

« previous php.bugs (#202314) next »