New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it possible to find all references to some object? #26
Comments
cc @hhellyer |
It should be fairly practical. For the nodeinfo command I used the logic from @indutny's inspect functions to return object ref's directly (instead of as strings) which is the core of what this command would need. I can try and take a look at doing this this week. Would it be best to make it an extension of findjsobjects so it's familiar to mdb_v8 users or a new command since it probably won't be exactly the same as the mdb version and might have it's own set of options? |
It makes sense to me to create an extension for it. As an less compatible alias we could use |
@hhellyer thanks for the heads up! |
Thanks a lot. It would be great to see this feature in llnode. Little offtopic: |
@unikoid It's not looking to difficult to add. I'll hopefully put up a branch with a prototype sometime this week. Are there any features other than just simply listing all the objects that refer to another object that you need? (I was going to put the referring object id, it's name and the referring field name in the output. How are you trying to load the plugin? From the python interface or C++? I'm not sure the lldb API docs are that up to date but I have the source checked out so if you can be a bit more specific I can check that. |
@hhellyer I think there is a way to write a python script that will just execute various commands. I doubt that it will be efficient, though. |
The whole LLDB SB (Scripting Bridge) API is mirrored from C++ to Python using SWIG so theoretically you can do anything in Python that you can do in C++. Unfortunately I don't believe there's a call to load a plugin in the API. Searching for calls to the plugin loading function only hits the code for the "plugin load" command. I don't think the plugin loading feature is exposed. You could get around it by loading the llnode code as a library and calling into it but it's probably quite a lot of work. I'll try and make a prototype for findrefs available soon. |
@yjhjstz has been using the C++ scripting interface to call plugin commands, see https://github.com/yjhjstz/llnode. I think he issues the 'plugin load' command first via the SBCommandInterpreter, then the llnode commands.
As Fedor says, it is likely to be a bit inefficient if the entire heap is being scanned |
@unikoid - I've put a (very rough) prototype here: https://github.com/hhellyer/llnode/tree/findreferences_prototype |
@hhellyer Good news, thanks a lot! |
@unikoid - I've pushed an update. References in arrays (or rather references in elements, indexed by number rather than name) should now be found. |
@hhellyer I tried your prototype, but it seems to be not working for my case. This may be a problem with my dump, though, as I'll retry with another dump a bit later. |
@unikoid - It should work if the findjsobjects command is working, they use the same code for locating all objects in memory. |
@hhellyer |
@unikoid Ok, I've tried it on a dump with a much fuller heap and it's taking a while for me too. I'll investigate further to see if I can find out why and if I can improve the performance. |
@unikoid Ok, so the problem was I was getting every property name in every object (inflating those to strings) then looking up the value for those. I've got a local patch that gets back all the name/value pairs and checks the value of the ref before inflating the key name. That results in a pretty huge speed up in local testing. I'll tidy it up and push it to the prototype branch on Monday. |
@unikoid I've pushed an update that should give much better performance when running findrefs. String creation is also the highest profiling part of the findjsobjects command so I might take a look and see if I can improve that sometime but if I do I'll do it under a separate issue. |
@hhellyer thanks, I tried the latest version, but still no luck. I'm going to try to debug this myself today. |
@hhellyer I tried to debug it a bit. Could you please help me with one question:
while being inside of |
@unikoid It's the raw_ field that contains the address you should use with v8 inspect. The v8_ field is a reference to llnodes v8::LLV8 C++ object.
should show you the object. If you post the output I'll see if there's anything I can do. |
@hhellyer thanks.
? |
I see that sometimes when the address doesn't point to a well formed object for some reason. It might be worth just checking the dump you are using. How did you generate it? I think the ones generated by --abort_on_uncaught_exception are likely to be safe but the rest of the time v8 could be doing anything. A dump generated mid-garbage collection is likely to be bad but the rest of the time depending on when and how the dump was created there could be half formed objects on the heap which I wouldn't be surprised to find causing problems. |
Add implemenetation of v8 findrefs that searchs for objects that refer to the object id passed to v8 findrefs. Displays the object id of the referrer and the field name that referred to the object id. Example: (lldb) v8 findrefs 0x00003a1aca0e3051 0x3a1aca0e3369: Object.obj=0x3a1aca0e3051 Fixes: https://github.com/indutny/llnode/issues/26
Add implementation of v8 findrefs that searches for objects that refer to the object id passed to v8 findrefs. Displays the object id of the referrer and the field name that referred to the object id. Example: (lldb) v8 findrefs 0x00003a1aca0e3051 0x3a1aca0e3369: Object.obj=0x3a1aca0e3051 Fixes: https://github.com/indutny/llnode/issues/26 Review: nodejs#32
Hello,
First, thank you for the job you've done, llnode is great debugging tool.
mdb_v8 findjsobjects command has one useful feature:
Is it possible to achieve the same with lldb + llnode? If not, do you have any plans to implement this feature?
The text was updated successfully, but these errors were encountered: