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

reset pointer to prevent memory corruption #127

Merged
merged 1 commit into from
May 17, 2020
Merged

reset pointer to prevent memory corruption #127

merged 1 commit into from
May 17, 2020

Conversation

cjihrig
Copy link
Collaborator

@cjihrig cjihrig commented May 16, 2020

The code in path_resolver.c that replaces forward slashes with
backslashes on Windows did not work. It modified a chunk of
memory immediately following the memory it was meant to update.
This was leading to crashes on Windows in the Node.js test
suite ~1-2% of the time. This commit resets the pointer to the
correct location for the calculations.

Side note: this logic was broken and the slashes weren't actually
being updated, but the tests were still passing on Windows. This
logic might not really be needed after all?

Node.js stress test (4,000 runs spread across 4 windows machines): https://ci.nodejs.org/view/Stress/job/node-stress-single-test/73/ ✔️
Also resolves: nodejs/node#33403

The code in path_resolver.c that replaces forward slashes with
backslashes on Windows did not work. It modified a chunk of
memory immediately following the memory it was meant to update.
This was leading to crashes on Windows in the Node.js test
suite ~1-2% of the time. This commit resets the pointer to the
correct location for the calculations.

Side note: this logic was broken and the slashes weren't actually
being updated, but the tests were still passing on Windows. This
logic might not really be needed after all?
Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

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

Almost all Windows APIs happily accept / as well as \, so yes, I guess it’s possible that this isn’t really needed? I guess the question is more whether paths that are processed this way end up being returned to WASM code and whether that code has specific expectations on the slashes?

@cjihrig
Copy link
Collaborator Author

cjihrig commented May 16, 2020

This is related to host paths only. WASM, AFAIK, should only be dealing in Unix style paths, and the paths here shouldn't be exposed to WASM at any point.

@cjihrig cjihrig mentioned this pull request May 16, 2020
@cjihrig
Copy link
Collaborator Author

cjihrig commented May 16, 2020

@addaleax do you have any preference on landing this as is vs. removing the path translation?

@cjihrig
Copy link
Collaborator Author

cjihrig commented May 17, 2020

I'm going to land this as is since the problem seems to be resolved. If it ends up causing any problems in the future it's easy enough to remove.

@cjihrig cjihrig merged commit 46103bf into master May 17, 2020
@cjihrig cjihrig deleted the bug branch May 17, 2020 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants