-
Notifications
You must be signed in to change notification settings - Fork 11
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
package ext2fs crashes Node 14.4.0 #76
Comments
@zvin Today we have learned this has to be addressed in the addon, i.e. here in the ext2fs package. It cannot be corrected in Node.js.
For better understanding there is more info at Node.js issue 32463, which caused above mentioned Node.js pull request 33321. One important insight seems to be:
I am not sure I can fix this quickly, because this here looks like a big package for someone new to it. Any hints? |
@zvin I am in Alas, this is not code I am fluent in recently. |
Now in Have added in
Seeing same address for s-data twice before it crashes. Apparently that is what now no longer is allowed per Node, as linked above. For example:
Here the slightly changed
|
It seems making a copy before the call is considered safe or recommended by Node coders. After a read one would have to copy back. I am trying in
and then trying in
I have tried a few things where the ??? is, including This also includes adding fields for buffer and size into the While I think this is the right idea, making a copy of the data, I fail at running successfully. One version I get something like Can someone more fluent with this code try this kind of copy before and after the call? |
Thanks for the investigation @srguiwiz , I'll have a look as soon as possible. |
Update in two sections, first current status here, then general analysis in next reply. If in addition to buffer we add two more local variables
and then in
that works fine. However, if keeping around the buffer in
as if the Buffer no longer is valid, as plausible explanation coming back after an async As mentioned earlier, this must be done with awareness of type, when buffer is null, and only for The plan was to switch to With that annoying change in Node 14 it doesn't run at all. For now anything that prevents if from crashing is good, even with an extra copy. While using the adjective "annyoing" I also respect that Node developer folk have to "deal with" what is given to them by V8 developer folk. It wasn't within one organization that this could have been "discussed better before releasing". Important to consider regarding testing this problem: Minimal activity doesn't crash, because minimal activity happens not to reuse any address with |
A discussion of In most other circumstances one could angrily complain about Node 14 as described, asking "why do you guys have such a ridiculous constraint?" In this special case, if I understand it correctly, they have a free pass because Node is made with V8, which are made by two different organizations. Those who develop V8 have a different focus than those who then develop Node, which incorporates V8. The constraint is, one must not accidentally invoke This has specific implications for coding the Part of the challenge here are the layers of calls back and forth beweent Node and C++. The The This matters because when This matters because the Therefore, the Therefore I am looking at ways to enable the For writes, Having listed this, I don't want to limit anyone's thoughts. |
I am now seeing in As mentioned, had no luck with Have not done the steps described in this one reply. Stepping away from computer for a while. |
Apparently it is possible to pass back to C++ the
From there I was trying to look at them in
Again, I am just rigging here without being properly set up for C++ development or having refreshed my C++ in years. There could be some obvious flaw in this. I am thinking, maybe something happens similar to |
Also, I happen to have noticed all reads seem to be size 1024 in my test with ext2. If so, maybe alternatively it would be possible to allocate a buffer that size from JavaScript, from |
This should no longer be an issue since v3.0.0 as we build it as a WASM module. |
This crash appears to be related to Node.js pull request 33321 , which apparently is a partial relief, but not a full fix. I report here too, because I cannot tell yet who should fix it how.
To compare, the example given here runs fine with Node 12.18.1, an LTS, and crashes with Node 14.4.0, latest.
Reproduce with a small project with
package.json
and with
index.js
If it runs fine (Node 12.18.1) it shows expected output like
If it fails (Node 14.4.0) it shows something like
This trace is from running in CentOS 7.8. For correctness, doing the required
npm rebuild
between changing Node versions withsudo n
.This problem in Node.js apparently occurs with concurrency and addon code, and hence appears only in some use cases of Node, and that apparently is why the first partial fix there has been accepted. Apparently, as shown here, there is still a problem.
The text was updated successfully, but these errors were encountered: