src,etw: fix event 9 on 64 bit Windows #15563
Conversation
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable publishes a 64 bit integer, making the event undecodable.
joaocgreis
added
lts-watch-v6.x
windows
nodejs-github-bot
added
c++
IMHO assigning |
mscdex
added
the
trace_events
src/node_win32_etw_provider-inl.h
Outdated
| @@ -253,7 +247,11 @@ void NODE_V8SYMBOL_ADD(LPCSTR symbol, | |||
| } | |||
| void* context = nullptr; | |||
| INT64 size = (INT64)len; | |||
| INT_PTR id = (INT_PTR)addr1; | |||
| #if defined(_WIN64) | |||
| INT32 id = 0; | |||
There was a problem hiding this comment.
Why do we not just use the lower 32 bits on 64 bit? That is, why not just have the non-64 bit version on 64 bit too?
Also agree with @refack that using addr1 as the id is somewhat arbitrary but I don't know if v8 has a better (and more stable/deterministic) id that we can use here- in ChakraCore we use our "function id" which I believe is somewhat stable across runs of node because it's incremented in order of in which the function is compiled- this allows us to collect a trace, and then run with additional tracing flags for just that function id to get more details on that function. Does v8 have something stable like that that we can use here? (cc @fhinkel)
Do we know that the lower 32 bits won't overlap? If there's something that limits the addresses to a continuous 4GB space we could do that. Either way, I'm not sure we should encourage the use of this ID in it's current form, and the address is already available in the field |
|
We don't know that the bits wont overlap but in practice unless the app uses > 4GB, I believe the Windows memory manager would continue to allocate it in a contiguous address space (at least, that was my recollection from how ChakraCore organized its pages 😄)- but even if that assumption was incorrect, probabilistic overlapping is still probably better than the current behavior which is guaranteed collision- and while I agree we shouldn't encourage use of this ID, the Windows tools that decode JS stacks (Windows Performance Analyzer/VS etc) probably already have a dependency on this ID being more or less unique (I think the real solution here is to have a stable id that's provided by v8, but in the interim my instinct is that the lower 32 bits is better than nothing) |
|
@digitalinfinity if you believe having the value is useful, I'm ok with having it. Updated, PTAL. |
The upside I see is less code ;) |
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable published a 64 bit integer, making the event undecodable. PR-URL: #15563 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
|
CI: https://ci.nodejs.org/job/node-test-pull-request/10299/ , failures unrelated but ran linter again: https://ci.nodejs.org/job/node-test-linter/12074/ . Landed in 510cab7 |
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable published a 64 bit integer, making the event undecodable. PR-URL: nodejs#15563 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable published a 64 bit integer, making the event undecodable. PR-URL: #15563 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable published a 64 bit integer, making the event undecodable. PR-URL: nodejs/node#15563 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable published a 64 bit integer, making the event undecodable. PR-URL: #15563 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable published a 64 bit integer, making the event undecodable. PR-URL: #15563 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable published a 64 bit integer, making the event undecodable. PR-URL: #15563 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable published a 64 bit integer, making the event undecodable. PR-URL: #15563 Reviewed-By: Refael Ackermann <[email protected]> Reviewed-By: Hitesh Kanwathirtha <[email protected]>
The event manifest specifies the MethodID field as a 32 bit integer. The 32 bit node executable publishes this correctly, but the 64 bit executable publishes a 64 bit integer, making the event undecodable.
This fix makes the event decodable again by publishing it as 0 in 64 bit systems. This way the manifest is not changed, so this fix is semver-patch and can be backported to LTS. Note there are already other dummy values on this event and the address is already published correctly as a pointer in another field. In the future, this should probably be changed to a meaningful value provided by the engine in use.
cc @nodejs/platform-windows
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
src, etw.