Take into account unreferencable circular references #83
Comments
|
I have a prototype change available (https://github.com/mathieuk/php-meminfo/tree/browse_object_store) that will somewhat detect that an instance of Y and X still exist in memory at the time. The output for now would be: And in the output of meminfo_dump(): Right now it doesn't add the properties of the objects yet, because I haven't figured out how to do that. But would you like to add this in this way? I think it would be interesting to, say, overload the NEW operator and keep track of where objects are instantiated to give the user a fighting chance of determining where their cycles are originating. |
|
Hey @mathieuk , Can you elaborate on what would be your use case? The objects that have circular reference but that will be collected by the Garbage Collector don't constitute a memory leak, as the memory is going to be cleanup. So dumping them will not help understand memory leaks. By the way, what you describe used to be the behavior of PHP Meminfo: dumping the content of the object store (https://github.com/BitOne/php-meminfo/blob/v0.1.0/meminfo.c#L132 for history). This had several drawbacks:
These are the reasons why I decided to change the exploration way by going through all execution frame + all statically defined variable. |
|
Hi @BitOne, I've had a few brush-ins with circular references and when you're using frameworks (like Laravel, which I'm using) it can be a real hassle to find out where things are going wrong. In my case, where database connections were being kept open in a job worker despite code trying to close it, it turned out that the Laravel database class has a method It took me forever to find that. So, my goal was to improve that situation by giving the developer more information. I figured that by detecting all objects that haven't been seen in the stackframes/static properties yet you'd atleast see that there is (potential for) a circular reference that can cause issues. But, that isn't quite enough: as you still have little information about why this is happening. So, to detect this, you would have to know where references are happening and which are still alive at a certain point. I've been thinking I could maybe look into overloading the ASSIGN, ASSIGN_DIM, ASSIGN_OBJ opcodes and keep track of (object) assignments. It'd be a big slow down for the code; but I suppose that's OK in this debugging situation. By finding the collected references not in I suppose this is getting a bit out of the What do you think? Is this something you think'd be useful to have in meminfo? |
|
Hi @mathieuk , Thanks for the detailed explanation. So if I understand correctly, you had a situation with a circular reference between objects without any living reference (exec frame or static) that was not collected by the garbage collector. If that's the case, the problem is in the PHP garbage collector itself: it's a bug of the Zend PHP engine. And in this case, this falls outside of PHP Meminfo scope, as it's not anymore a memory leak due to the PHP program, but a bug of the PHP Zend Engine. But maybe PHP Meminfo doesn't have all the proper entry points yet, and this was not a dangling reference, but something that PHP Meminfo did not detect. But I think I'm getting convinced by the idea of having something to dump all objects in memory, using the previous code ;) . At least to debug PHP Meminfo itself: if a lot of objects appears in the "non-accessible" objects, then something is missing. Maybe as a different part of the output format, by providing an option to meminfo_dump? And by the way, if you have a working example of your use case that you can share, that would be wonderful ;) |
Hey - I have a use-case that may be of interest - a project where I've just spent the last six or so hours tracking down memory leaks with the help of this package. The first 4 hours were relatively fruitless, but then I added the suggested improvement from @mathieuk (to identify reference-cycle leaks) and the last two hours have been much more productive! Nevertheless, you've built a wonderful tool! |
A source of (perceived) memory leaks will be circular references (especially to objects) that haven't been picked up by the GC yet.
php-meminfoshould provide insight into objects that aren't currently referencable from the PHP userland but are still active in memory.Example script where
php-meminfodoesn't report the existance of the objects:The output will be:
The text was updated successfully, but these errors were encountered: