Skip to content
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

Merged
merged 1 commit into from Oct 14, 2021

Conversation

CezaryKulakowski
Copy link
Contributor

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

Release Notes

Notes: fixed event with invalid timestamp in trace log

@CezaryKulakowski CezaryKulakowski requested a review from a team as a code owner October 8, 2021 10:00
@electron-cation electron-cation bot added the new-pr 🌱 PR opened in the last 24 hours label Oct 8, 2021
@deepak1556 deepak1556 added semver/patch backwards-compatible bug fixes target/14-x-y labels Oct 8, 2021
@deepak1556
Copy link
Member

/cc @codebytere this is worth upstreaming.

@@ -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
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ELECTRON_USE_THREE_WAY_MERGE_FOR_PATCHES=1 gclient sync --with_branch_heads --with_tags
is the command used by linux and macOS ci.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Member

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

Copy link
Contributor Author

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.

@electron-cation electron-cation bot removed the new-pr 🌱 PR opened in the last 24 hours label Oct 9, 2021
@zcbenz
Copy link
Member

zcbenz commented Oct 11, 2021

I wonder if we can set performance::performance_v8_start = PERFORMANCE_NOW() in ElectronRendererClient to avoid adding a patch?

@CezaryKulakowski
Copy link
Contributor Author

@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?

@zcbenz
Copy link
Member

zcbenz commented Oct 11, 2021

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.

@codebytere
Copy link
Member

@zcbenz i'll open an upsteam PR.

@codebytere
Copy link
Member

Open at nodejs/node#40405

@ckerr
Copy link
Member

ckerr commented Oct 13, 2021

linux-x64-testing-tests is failing with this error:

AssertionError: the trace output file is suspiciously large (116.525390625KB),
        check "/tmp/trace.json": expected 116.525390625 to be below 10
    at Context.<anonymous> (electron/spec-main/api-content-tracing-spec.ts:64:41)

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?

@codebytere
Copy link
Member

codebytere commented Oct 14, 2021

@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.
@CezaryKulakowski
Copy link
Contributor Author

@codebytere I've force pushed branch rebased to the newest main.

@jkleinsc jkleinsc merged commit 11db6a7 into electron:main Oct 14, 2021
@release-clerk
Copy link

release-clerk bot commented Oct 14, 2021

Release Notes Persisted

fixed event with invalid timestamp in trace log

@trop
Copy link
Contributor

trop bot commented Oct 14, 2021

I have automatically backported this PR to "14-x-y", please check out #31421

@trop
Copy link
Contributor

trop bot commented Oct 14, 2021

I have automatically backported this PR to "15-x-y", please check out #31422

@trop
Copy link
Contributor

trop bot commented Oct 14, 2021

I have automatically backported this PR to "16-x-y", please check out #31423

codebytere added a commit to nodejs/node that referenced this pull request Oct 15, 2021
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>
t57ser pushed a commit to t57ser/electron that referenced this pull request Oct 27, 2021
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.
t57ser pushed a commit to t57ser/electron that referenced this pull request Oct 27, 2021
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.
t57ser pushed a commit to t57ser/electron that referenced this pull request Oct 29, 2021
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.
t57ser pushed a commit to t57ser/electron that referenced this pull request Oct 29, 2021
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.
t57ser pushed a commit to t57ser/electron that referenced this pull request Oct 29, 2021
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.
t57ser pushed a commit to t57ser/electron that referenced this pull request Oct 29, 2021
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.
targos pushed a commit to nodejs/node that referenced this pull request Nov 4, 2021
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
semver/patch backwards-compatible bug fixes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants