-
Notifications
You must be signed in to change notification settings - Fork 16.2k
fix: libuv hang when nodeIntegrationInSubframes enabled #27582
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
Conversation
8e1a52e
to
d407725
Compare
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.
This works & seems reasonable.
It's a little cumbersome though. If someone else has a better idea I'd be happy for an alternate 🙂
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.
If that's the case, that means the last call to node_bindings_->PrepareMessageLoop() may still be active and calling it twice in a row can hang the page.
If this is the root cause, may be we can fix it by checking whether backend fd has changed?
Also when calling PrepareMessageLoop
, I think we should probably do a release first to avoid possible resources leaks.
void PrepareMessageLoop() {
int backend_fd = uv_backend_fd(uv_loop_);
if (backend_fd == old_backend_fd)
return;
if (IsInitialized(embed_sem_))
FreeTheHandles();
...
}
Hey, is there any news about this issue? Is this pull request functional to fix the problem? If so, is there any chance I could get a compiled version of it (or instructions to compile it), so I could test and verify it resolves the issue (and continue working on the project affected by it)? |
d407725
to
4e3ebb7
Compare
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.
LGTM
Not the end of the world, but aren't we leaking the semaphore on reload now? |
c53bce9
to
11a84b9
Compare
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 good with current change, but we need to fix leak of uv handles on reloads with another PR.
Looks like this is legitimately dying on Windows -
Investigating now 🤔 |
It looks like this bug is only present on Linux and macOS - and |
5356c37
to
5e68d46
Compare
We need to prevent duplicate initializations even if it does not seem to cause problems for now. On Windows you can access IOCP handle via |
cb2d939
to
8723fe6
Compare
I was unable to backport this PR to "12-x-y" cleanly; |
@codebytere has manually backported this PR to "12-x-y", please check out #27879 |
@codebytere has manually backported this PR to "11-x-y", please check out #27880 |
@codebytere has manually backported this PR to "10-x-y", please check out #27881 |
Description of Change
Closes #27457.
Refs 13f319e
If we're loading Node.js into a subframe and we've already initialized the Node.js integration, that means we're in
DidCreateScriptContext
because a new subframe was created, not because we've reloaded the page. If that's the case, that means the last call tonode_bindings_->PrepareMessageLoop()
may still be active and calling it twice in a row can hang the page. In that case, don't re-prepare the message loop.cc @deepak1556 @zcbenz @MarshallOfSound @ckerr
Checklist
npm test
passesRelease Notes
Notes: Fixed an issue where libuv might hang with multiple subframes when
nodeIntegrationInSubframes
is enabled.