I've run into a really crazy data corruption issue that looks to be caused by running dpm() on an object. I was dpm'ing $data inside of some token_replace() code, and it was causing the uid of the user object to be set to 1. I think it might actually be a PHP bug, but I can't reproduce it outside of my site code, though it does happen on both Ubuntu's PHP 5.5.9 and a PPA for 5.5.16.
Inside of krumo, there's a _hive() method that helps to handle recursive object references. It attempts to increment a variable that hasn't been set, while silencing the notice at the same time. The actual line that was modifying the uid is ? @($bee->$_recursion_marker++)
. Also, the actual recursion_marker value never gets set, though in a test script incrementing a missing property on an object is setting it to 1.
Rather than continue debugging to see why this is happening, I've cleaned up the code to be a little more defensive so it doesn't need to silence the notice in the first place. This patch applies against both 8.x and 7.x.
Comment | File | Size | Author |
---|---|---|---|
#1 | 2332361.1-hive-object-corruption.patch | 1.04 KB | deviantintegral |
Comments
Comment #1
deviantintegral CreditAttribution: deviantintegral commentedComment #2
tomyinhauser CreditAttribution: tomyinhauser commentedThis bug drove me crazy. Thanks for sharing!
Comment #3
willzyx CreditAttribution: willzyx commentedMoving to 7.x since krumo was removed from the 8.x branch in #2620790: Remove Krumo library and Krumo integration from devel
Comment #4
apotek CreditAttribution: apotek commentedWe've been using 2332361.1-hive-object-corruption.patch in production for well over a year with no problems. Thanks @deviantintegral
Comment #5
salvisPatch does not apply anymore due to a prior fix in #2366797: Running dpm on global $user object logs the user in as user 1.. I think that took care of this issue.
Please reopen with a new patch if more work is needed.
Thanks anyway for the patch and reviews!