Heap snapshot does not seem to work anymore on 1.11 (in chrome profile loader) #54414
Comments
KristofferC
added
regression
|
Does the snapshot load in vscode's viewer? |
|
In VSCode I can load the 1.11 snapshot but not the 1.10 one... |
KristofferC
changed the title
|
AFAIK the VS Code heap snapshot viewer doesn't allow diffing two heap snapshots, unlike the Chromium Dev Tools? So I guess there's currently no way to diff heap snapshots 🫤. |
Say that: * VS Code may be used for viewing heap snapshots. Important because Chromium currently may *not* be used for this on Julia v1.11 and up: JuliaLang#54414 * Firefox can't be used.
|
Any help figuring out why would be appreciated. They seem to expect different metadata. See the PRs that have changed it |
|
Trying to get to the bottom of this. Supposedly this is a valid V8 structure {
"snapshot": {
"title": "Heap Snapshot",
"uid": 1,
"meta": {
"node_fields": ["type", "name", "id", "self_size", "edge_count"],
"node_types": [
["object", "closure", "regexp", "string", "number", "native", "synthetic", "concatenated string", "sliced string"],
"string",
"number",
"number",
"number"
],
"edge_fields": ["type", "name_or_index", "to_node"],
"edge_types": [
["context", "element", "property", "internal", "hidden", "shortcut", "weak"],
"string_or_number",
"node"
]
},
"node_count": 1000,
"edge_count": 5000
},
"strings": [
"",
"(root)",
"Object",
"Array",
"foo",
"bar",
/* ... other strings ... */
],
"nodes": [
0, 1, 2, 3, 4, /* ... node data ... */
],
"edges": [
0, 1, 2, /* ... edge data ... */
],
/* ... other sections ... */
}
A julia example I just collected {
"snapshot": {
"meta": {
"node_fields": ["type", "name", "id", "self_size", "edge_count", "trace_node_id", "detachedness"],
"node_types": [
["synthetic", "jl_task_t", "jl_module_t", "jl_array_t", "object", "jl_datatype_t", "String", "jl_svec_t", "jl_sym_t"],
"string",
"number",
"number",
"number",
"number",
"number"
],
"edge_fields": ["type", "name_or_index", "to_node"],
"edge_types": [
["internal", "element", "hidden", "property", "binding"],
"string_or_number",
"from_node"
],
"trace_function_info_fields": ["function_id", "name", "script_name", "script_id", "line", "column"],
"trace_node_fields": ["id", "function_info_index", "count", "size", "children"],
"sample_fields": ["timestamp_us", "last_assigned_id"],
"location_fields": ["object_index", "script_id", "line", "column"]
},
"node_count": 1759206,
"edge_count": 5447107,
"trace_function_count": 0
},
"trace_function_infos": [],
"trace_tree": [],
"samples": [],
"locations": [],
"nodes": [
0, 0, 0, 0, 4, 0, 0,
0, 1, 1, 0, 6, 0, 0,
...
"edges":[
0,1,7,
0,2,14,
...
"strings":[
"",
"GC roots",
...
}#53833 which fixed opening in VSCode's viewer, and likely broke chrome devtools made these changes
References: |
|
The problem appears to be the inclusion of without it vscode cannot load the heapsnapshot, but chrome devtools can. |
|
Dev tools parsing for those fields (which fails if they are there, but the line numbers don't correspond to here) It'd be helpful to find the exact files & lines these are coming from in devtools, but I guess these js files were minified |
|
The error above is to this (in an unminified version of heap_snapshot_worker,js) https://gist.github.com/IanButterworth/9fb742180ee6e682e04d34819fd9d500#file-heap_snapshot_worker-js-L693 So somehow the inclusion of is preventing |
|
https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/memory-problems/heap-snapshot-schema not sure if this is helpful but I always drop it. |
|
That's linked above. I think this is a bug in what each expects to be there. |
This comment was marked as outdated.
This comment was marked as outdated.
|
Yep. That's at the bottom of that comment |
|
I see that a vscode-generated heapsnapshot opens in chrome dev tools, and visa-versa. It's just julia ones that don't open in dev tools. Some summaries Juliachromevscode |
|
We don't populate "locations". According to https://learn.microsoft.com/en-us/microsoft-edge/devtools-guide-chromium/memory-problems/heap-snapshot-schema
But if you take the number of node entries in the vscode one as an example: If we can figure out the right size to zero pad to, it'd be worth trying I think. |
|
Found the issue! The order of the fields in the json object is critical for dev tools! I guess their JSON parser doesn't just load the whole json object in then process it, but does some processing on the fly.. |
Trying to load this in Chrome leads to
On 1.10 the same procedure works fine.
The text was updated successfully, but these errors were encountered: