-
Notifications
You must be signed in to change notification settings - Fork 15.4k
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
fix: event with invalid timestamp in trace log #31349
Conversation
/cc @codebytere this is worth upstreaming. |
patches/node/.patches
Outdated
@@ -14,6 +14,7 @@ chore_allow_the_node_entrypoint_to_be_a_builtin_module.patch | |||
chore_add_context_to_context_aware_module_prevention.patch | |||
chore_read_nobrowserglobals_from_global_not_process.patch | |||
enable_31_bit_smis_on_64bit_arch_and_ptr_compression.patch | |||
fix_event_with_invalid_timestamp_in_trace_log.patch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@CezaryKulakowski Is this patch order correct, looks like the sync failure is related to it. Can you please look into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deepak1556 I've just checked again than gclient sync passes with no error on my Windows 10 and macOS.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can also see that sync was fine on Windows. Is gclient run with some additional options on buildbots on macOS and Linux?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line 261 in 31e295a
ELECTRON_USE_THREE_WAY_MERGE_FOR_PATCHES=1 gclient sync --with_branch_heads --with_tags |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've just run this command on top of my branch on macOS and gclient was successful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to move my patch under another one which also modifies src/env.cc
. Unfortunately I am not able to check locally if it works as there is no problem on my machines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah not sure what is the issue, /cc @jkleinsc
I'm going to move my patch under another one which also modifies src/env.cc
Sounds good, it is better if you can just append the patch to the list
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems my fixup solved the problem. But it would be good to know how to reproduce the problem locally to avoid such problems in the future. I guess the best tip is to apply new patches on top of the rest of the patches and put it at the end of file .patches.
I wonder if we can set |
@zcbenz we could but current fix looks like more valid one. I don't know the node's development process: is it possible to upstream this change to them? |
We would like to minimize the number of patches on Node.js, so generally we prefer having ugly code in Electron than patching Node.js. For this patch I think it should be fine to be upstreamed, can you try creating a pull request at https://github.com/nodejs/node? If Node.js maintainers are fine with it I have no problem merging this. |
@zcbenz i'll open an upsteam PR. |
Open at nodejs/node#40405 |
linux-x64-testing-tests is failing with this error:
Which superficially seems related to the subject of this PR. Is this related, and if so, is this an actual issue, or is it just that the file has changed because the timestamps have changed? |
@ckerr this was fixed in #31409 and is unrelated so @CezaryKulakowski if you could rebase we can get this merged. |
When node is started within Electron's environment it doesn't initialize v8 and time of v8's start is never set. As a result we log v8's start time as 0 and it breaks timestamps in the trace log. With this change we log v8's start time only when it was initialized by node.
f658353
to
53cfb10
Compare
@codebytere I've force pushed branch rebased to the newest main. |
Release Notes Persisted
|
I have automatically backported this PR to "14-x-y", please check out #31421 |
I have automatically backported this PR to "15-x-y", please check out #31422 |
I have automatically backported this PR to "16-x-y", please check out #31423 |
PR-URL: #40405 Refs: electron/electron#31349 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
When node is started within Electron's environment it doesn't initialize v8 and time of v8's start is never set. As a result we log v8's start time as 0 and it breaks timestamps in the trace log. With this change we log v8's start time only when it was initialized by node.
When node is started within Electron's environment it doesn't initialize v8 and time of v8's start is never set. As a result we log v8's start time as 0 and it breaks timestamps in the trace log. With this change we log v8's start time only when it was initialized by node.
When node is started within Electron's environment it doesn't initialize v8 and time of v8's start is never set. As a result we log v8's start time as 0 and it breaks timestamps in the trace log. With this change we log v8's start time only when it was initialized by node.
When node is started within Electron's environment it doesn't initialize v8 and time of v8's start is never set. As a result we log v8's start time as 0 and it breaks timestamps in the trace log. With this change we log v8's start time only when it was initialized by node.
When node is started within Electron's environment it doesn't initialize v8 and time of v8's start is never set. As a result we log v8's start time as 0 and it breaks timestamps in the trace log. With this change we log v8's start time only when it was initialized by node.
When node is started within Electron's environment it doesn't initialize v8 and time of v8's start is never set. As a result we log v8's start time as 0 and it breaks timestamps in the trace log. With this change we log v8's start time only when it was initialized by node.
PR-URL: #40405 Refs: electron/electron#31349 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com>
When node is started within Electron's environment it doesn't
initialize v8 and time of v8's start is never set. As a result
we log v8's start time as 0 and it breaks timestamps in the
trace log. With this change we log v8's start time only when
it was initialized by node.
Bug: #31348
Description of Change
Checklist
npm test
passesRelease Notes
Notes: fixed event with invalid timestamp in trace log