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

Edit report at https://bugs.php.net/bug.php?id=67807&edit=1 ID: 67807 Updated by: php-bugs@lists.php.net Reported by: atlantisnova at gmail dot com Summary: Object passed by reference becomes a string -Status: Feedback +Status: No Feedback Type: Bug Package: Scripting Engine problem Operating System: Debian Linux PHP Version: 5.4.4 Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. Previous Comments: ------------------------------------------------------------------------ [2016-07-14 11:26:04] dmitry@php.net I can't reproduce this with PHP-5.3 and above. ------------------------------------------------------------------------ [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! ------------------------------------------------------------------------ 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