Open mathieuk opened 6 years ago
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:
$ php -dextension=meminfo.so test.php
Found unseen alive object: X #2 (0x7fb51a465820)
Found unseen alive object: Y #1 (0x7fb51a4657d0)
And in the output of meminfo_dump():
"0x7fb51a465820": {
"class" : "X",
"is_root" : false,
"frame" : "<OBJECTS_IN_OBJECT_STORE>",
"object_handle" : "2",
"type" : "object",
"size" : "56"
} ,
"0x7fb51a4657d0": {
"class" : "Y",
"is_root" : false,
"frame" : "<OBJECTS_IN_OBJECT_STORE>",
"object_handle" : "1",
"type" : "object",
"size" : "56"
}
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:
gc_collect_cycles()
before calling PHP Meminfo, and they ended with a lots of objects that were going to be collected by the GC and mistaken them for the real memory leak. This created frustration and confusionThese 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 getDoctrineConnection()
that I called somewhere, which calls into Doctrine\DBAL\Connection - which creates a circular reference to itself. I actually wrapped those calls with gc_enable() and gc_collect_cycles() but it never collected it.
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 visited_items
I think could you could then detect dangling references which would be interesting to inspect when you have that issue.
I suppose this is getting a bit out of the meminfo_dump()
scope; though it might still fit in the extension as a different feature.
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 ;)
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 gc_disable()
is called at the beginning of execution because the cycle counter slows stuff down, and it's very important that the application (a static analysis tool) is fast, especially when running as a language server when used with an IDE.
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-meminfo
should provide insight into objects that aren't currently referencable from the PHP userland but are still active in memory.Example script where
php-meminfo
doesn't report the existance of the objects:The output will be: