-
Notifications
You must be signed in to change notification settings - Fork 29.7k
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
Node 10 profiler path output regression on Windows #20891
Comments
I temporary use the following solution: node --prof node_modules/webpack/bin/webpack.js --mode production
sed -r 's/C\:\\[^,]+/"&"/g' isolate-[IDENTIFIER]-v8.log | sed -r '/C\:./ { s/\\/\//g }' > converted
node --prof-process converted > processed.txt It results in the following output: ...
[Shared libraries]:
ticks total nonlib name
49 80.3% "C:/Program Files/nodejs/node.exe"
9 14.8% "C:/WINDOWS/SYSTEM32/ntdll.dll"
... |
I confirm the issue still exists with Node 10.9.0.
I tried to apply similar fixes like adding |
Seems like this is an upstream bug and not directly related to Node.js. @nodejs/v8 PTAL. |
Seems like this just got fixed upstream: https://chromium.googlesource.com/v8/v8.git/+/29879461ceb4bc9b84b0ec38e4dd192fbf884dc2. I asked for a backport to 6.8 and I'll get that in if it's accepted. |
@BridgeAR closing this since this was fixed upstream and will be landed on |
@ryzokuken Reopening this as for Node.js 10 we'll probably need to float a V8 backport. |
So, this is still an issue with v10.x. Can we at least float the change from https://chromium-review.googlesource.com/c/v8/v8/+/1186625/2/tools/profile.js ? /cc @nodejs/platform-windows @nodejs/v8 |
Cherry-pick PR - #24555 |
Original commit message: Stop manual unescaping of script source data when preprocessing logs. It appears that the fields are already being unescaped elsewhere, perhaps by the JSON writer. So if we unescape when adding the source filename and contents, unescaping will happen again later and plain backslashes will be interpreted as escape codes. Bug: v8:6240 Change-Id: Ic66b9017ae685d6dd12944ee8d254991e26fbd32 Reviewed-on: https://chromium-review.googlesource.com/1186625 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Bret Sepulveda <bsep@chromium.org> Cr-Commit-Position: refs/heads/master@{#55401} Refs: v8/v8@2987946 PR-URL: #24555 Fixes: #20891 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Original commit message: Stop manual unescaping of script source data when preprocessing logs. It appears that the fields are already being unescaped elsewhere, perhaps by the JSON writer. So if we unescape when adding the source filename and contents, unescaping will happen again later and plain backslashes will be interpreted as escape codes. Bug: v8:6240 Change-Id: Ic66b9017ae685d6dd12944ee8d254991e26fbd32 Reviewed-on: https://chromium-review.googlesource.com/1186625 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Bret Sepulveda <bsep@chromium.org> Cr-Commit-Position: refs/heads/master@{#55401} Refs: v8/v8@2987946 PR-URL: #24555 Fixes: #20891 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Original commit message: Stop manual unescaping of script source data when preprocessing logs. It appears that the fields are already being unescaped elsewhere, perhaps by the JSON writer. So if we unescape when adding the source filename and contents, unescaping will happen again later and plain backslashes will be interpreted as escape codes. Bug: v8:6240 Change-Id: Ic66b9017ae685d6dd12944ee8d254991e26fbd32 Reviewed-on: https://chromium-review.googlesource.com/1186625 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Bret Sepulveda <bsep@chromium.org> Cr-Commit-Position: refs/heads/master@{#55401} Refs: v8/v8@2987946 PR-URL: #24555 Fixes: #20891 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
Original commit message: Stop manual unescaping of script source data when preprocessing logs. It appears that the fields are already being unescaped elsewhere, perhaps by the JSON writer. So if we unescape when adding the source filename and contents, unescaping will happen again later and plain backslashes will be interpreted as escape codes. Bug: v8:6240 Change-Id: Ic66b9017ae685d6dd12944ee8d254991e26fbd32 Reviewed-on: https://chromium-review.googlesource.com/1186625 Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Commit-Queue: Bret Sepulveda <bsep@chromium.org> Cr-Commit-Position: refs/heads/master@{#55401} Refs: v8/v8@2987946 PR-URL: #24555 Fixes: #20891 Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: Bartosz Sosnowski <bartosz@janeasystems.com>
The fix for this landed in v10.14.2 #24555 |
This still seems to be an issue in v10.16.0 |
Confirmed still repro in v10.16 win10 |
Summary:
With Node 10 on Windows, the v8 log generated via
node --prof
no longer quotes paths correctly, causingnode --prof-process
to treat the backslashes in the paths as escape sequences.This causes a path like:
C:\Users\Ed\src\neutrino-dev\node_modules\webpack\lib\Stats.js
...to be output as:
C:\u0000\rc\u0000erder\node_modulesëck\u0000tats.js
...which doesn't make for the most readable profiles.
In addition, redirecting stdout when using
--prof-process
without the--preprocess
, results in a binary file (whereas if there is no redirection, text is output to the console as expected).I'm presuming this is a regression between v8 6.2 and 6.6.
STR:
node --prof node_modules\webpack\bin\webpack.js --mode production
node --prof-process --preprocess isolate-[IDENTIFIER]-v8.log > preprocessed.json
node --prof-process isolate-[IDENTIFIER]-v8.log > processed.txt
Expected:
Node 10.1.0 produces comparable output to Node 8.x, that correctly lists the filesystem paths for items in the profile.
Actual:
# Step 1 produces... (note difference in quoting)
Node 10.1.0:
Node 8.11.2:
# Step 2 produces...
Node 10.1.0:
Node 8.11.2:
# Step 3 produces...
Node 10.1.0 (note: the binary output only occurs when redirecting stdout to a file):
Node 8.11.2:
The text was updated successfully, but these errors were encountered: