-
Notifications
You must be signed in to change notification settings - Fork 18
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
::findjsobjects doesn't work properly with V8 4.5.x #32
Comments
This change is a work in progress to fix ::findjsobjects for core dumps generated by Node.js 4.0.x (and possibly later). A number of changes have been made to the layout of objects in V8 from V8 4.3.x and later, and these changes prevent ::findjsobjects from working as expected. The current status of this change fixes how mdb_v8 gets retrieves the constructor of a JavaScript object given its Map. There are other problems remaining, one of them being that the layout of instance descriptors seems to have changed too, and thus it is currently not possible to retrieve an instance's properties correctly with mdb_v8.
I've made a bit of progress, and at least now I'm able to retrieve the constructor for all objects, and thus
However, it still fails in other cases. One of the failure cases that I found is the following:
In other words, it seems that adding a property whose value is an instance of
However, as for
I'm investigating these issues, but any hint or help would definitely be appreciated. With my current changes, all tests but |
This change is a work in progress to fix ::findjsobjects for core dumps generated by Node.js 4.0.x (and possibly later). The current status of this change fixes how mdb_v8 gets retrieves the constructor of a JavaScript object given its Map. It also fixes the problem of accessing objects' properties that was caused by a typo in "v8db_propindex_mask" that should have been "v8db_prop_index_mask" (note the underscore in "prop_index") in my previous changes. It has a "fallbacks" members for v8_offets so that we can have a fallback for typed arrays' length's offset. Finally, this change allows ::findjsobjects to find Buffer instances and inspect them. However, due to how Buffer instances are implemented in node v4.x and later, they are currently seen by mdb_v8 as having a constructor named "Uint8Array" instead of "Buffer". Even though Buffer instances are actually now Uint8Array instances, their prototype is set to Buffer.prototype, and someBufferInstance.constructor.name returns 'Buffer', so mdb_v8 should be able to get 'Buffer' as the constructor name. It fixes TritonDataCenter#32 in its current state, and it represents some progress but I still want to investigate why we can't get the proper constructor name for Buffer instances.
#33 is a work in progress to fix this issue. |
This change is a work in progress to fix ::findjsobjects for core dumps generated by Node.js 4.0.x (and possibly later). The current status of this change fixes how mdb_v8 gets retrieves the constructor of a JavaScript object given its Map. It also fixes the problem of accessing objects' properties that was caused by a typo in "v8db_propindex_mask" that should have been "v8db_prop_index_mask" (note the underscore in "prop_index") in my previous changes. It adds a "fallback" member for v8_offsets so that we can have a fallback for typed arrays' length's offset. Finally, this change allows ::findjsobjects to find Buffer instances and inspect them. However, due to how Buffer instances are implemented in node v4.x and later, they are currently seen by mdb_v8 as having a constructor named "Uint8Array" instead of "Buffer". Even though Buffer instances are actually now Uint8Array instances, their prototype is set to Buffer.prototype, and someBufferInstance.constructor.name returns 'Buffer', so mdb_v8 should be able to get 'Buffer' as the constructor name. It fixes TritonDataCenter#32 in its current state, and it represents some progress but I still want to investigate why we can't get the proper constructor name for Buffer instances.
Do not warn if JSTypedArray type is missing. Use a separate V8_OFF_MAP_CONSTRUCTOR_OR_BACKPOINTER constant to store the constructor_or_backpointer offset, and set V8_OFF_MAP_CONSTRUCTOR with thatvalue if V8_OFF_MAP_CONSTRUCTOR is -1. Before that change, the same variable was used for both offsets, and for node versions < 4.x, it would result in V8_OFF_MAP_CONSTRUCTOR always being -1, which would break, among other things, get_map_constructor and thus ::findjsobjects.
Make changes according to dap's code review: - Formatting/indentation nits. - Print <Typed array of length N> when ::jsprinting a typed array. - Update tests accordingly.
Make changes according to dap's code review: - Do not warn if JSTypedArray type is missing. - Clarify/added comments. - Formatting/indentation nits. - Print <Typed array of length N> when ::jsprinting a typed array. - get_map_constructor fails if V8_OFF_MAP_CONSTRUCTOR is missing. - Update tests accordingly. Also, use a separate V8_OFF_MAP_CONSTRUCTOR_OR_BACKPOINTER constant to store the constructor_or_backpointer offset, and set V8_OFF_MAP_CONSTRUCTOR with that value if V8_OFF_MAP_CONSTRUCTOR is -1. Before that change, the same variable was used for both offsets, and for node versions < 4.x, it would result in V8_OFF_MAP_CONSTRUCTOR always being -1, which would break, among other things, get_map_constructor and thus ::findjsobjects.
This fixes ::findjsobjects for core dumps generated by Node.js 4.0.x (and possibly later). This change fixes how mdb_v8 retrieves the constructor of a JavaScript object given its Map. It also fixes the problem of accessing objects' properties that was caused by a typo in "v8db_propindex_mask" that should have been "v8db_prop_index_mask" (note the underscore in "prop_index") in my previous changes. It adds a "fallback" member for v8_offsets so that we can have a fallback for typed arrays' length's offset. Finally, this change allows ::findjsobjects to find Buffer instances and inspect them. However, due to how Buffer instances are implemented in node v4.x and later, they are currently seen by mdb_v8 as having a constructor named "Uint8Array" instead of "Buffer", so ::findjsobjects -c Buffer won't find any actual Buffer instances, instead one has to use ::findjsobjects -c Uint8Array.
This change fixes: - 32 bit v4.x node binaries with improper JSTypedArray length offset. - v4.0.0 and v4.1.1 node binaries that miss Map's bit_field3's type metadata by hardcoding its type.
This fixes ::findjsobjects for core dumps generated by Node.js 4.0.x (and possibly later). This change fixes how mdb_v8 retrieves the constructor of a JavaScript object given its Map. It also fixes the problem of accessing objects' properties that was caused by a typo in "v8db_propindex_mask" that should have been "v8db_prop_index_mask" (note the underscore in "prop_index") in my previous changes. It adds a "fallback" member for v8_offsets so that we can have a fallback for typed arrays' length's offset. Finally, this change allows ::findjsobjects to find Buffer instances and inspect them. However, due to how Buffer instances are implemented in node v4.x and later, they are currently seen by mdb_v8 as having a constructor named "Uint8Array" instead of "Buffer", so ::findjsobjects -c Buffer won't find any actual Buffer instances, instead one has to use ::findjsobjects -c Uint8Array.
#33 fixes ::findjsobjects for core dumps generated by Node.js 4.0.x (and possibly later). This change fixes how mdb_v8 retrieves the constructor of a JavaScript object given its Map. It also fixes the problem of accessing objects' properties that was caused by a typo in It adds a Finally, this change allows |
Even though I thought that #24 (which landed as 5a189dd) fixed mdb_v8's support for V8 4.5.x, it turns out that
::findjsobjects
is still broken.::findjsobjects
misses a significant part of valid JavaScript objects:However, when an object is created in a similar way, but without adding a property,
::findjsobjects
is able to find it and filtering by constructor name also works as expected:My theory so far is that the way an object's map is referenced from an object has changed. The constructor for an object used to be stored in the Map directly available from the object, but now one has to traverse the whole "transition tree" to find the original Map that contains some information about that object, including its constructor. The relevant upstream change seems to be https://codereview.chromium.org/950283002.
Before this issue is fixed, mdb_v8 1.0.0 will be pretty much unable to inspect objects on the heap.
#24 still had all tests passing because the changes in the tests that use
::findjsobjects
(https://github.com/joyent/mdb_v8/pull/24/files#diff-76b702a3fc1358227ab75b86a1a39284R46 and https://github.com/joyent/mdb_v8/pull/24/files#diff-1f7f4b61869c469eb7471735f5412183R68) silently prevented the actual tests from running, which lead me to believe that they were passing. Moreover, when running manual tests,::findjsobjects
still found a significant number of objects, didn't output any garbage and in some cases found all objects so everything appeared to be working as expected. These tests will need to be fixed too.The text was updated successfully, but these errors were encountered: