exit 3221225477 running with nodejs x32 on windows 64 in release mode about napi-rs HOT 14 CLOSED

Pointers created from into_raw must be returned to rust and freed with from_raw. If node tries to free these pointers, we have much bigger issues.

Also, looks like some of the napi examples use static cstrings as function parameters, so I don’t think node tries to free them. It also doesn't make sense that it only happens on 32 bit windows.

Now that I'm thinking about it more, maybe it could be a calling convention problem. I believe win32 defaults to the "stdcall" calling convention instead of "cdecl". I'll try switching that later this week to test it out.

It's not a calling convention problem. I think it has to be a miscompilation from the rust compiler at this point.

from napi-rs.

The latest stable breaks it again.

I managed to hack around one error by leaking the cstring (i think the drop impl is generated incorrectly), but now i'm stuck on napi_set_named_property itself accessing invalid memory; the arguments passed in are probably invalid.

By inserting a debug statement, the mimalloc accesses invalid memory so i removed it, but now the vec in the cstring accesses invalid memory on construction.

from napi-rs.

Setting opt-level = 's' appears to generate good code on my computer, though it will probably break too in the future.

Actually, this also works with opt-level=1 and opt-level= 'z'. All of these disable inlining. I think Rust just inlines incorrectly on this target. If inlining is the issue, disabling inlining will probably be a good enough work around for the short term. Can you confirm whether setting opt-level='s' works?

from napi-rs.

I think this is a compiler codegen error. I don't think working around it is wise as opt-level='z' breaks it on my computer again. I found a similar issue: rust-lang/rust#67497. I think we should try to find a smaller example of this behavior and report it to the rust compiler repo.

Actually using:
cargo build --features \"latest\" --target i686-pc-windows-msvc --release && node ../scripts/index.js build --target-triple i686-pc-windows-msvc --release
still doesn't work on my computer when I pull from master, both stable and nightly. This issue should be reopened.
I'm on Windows 10.
My nightly: rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24)
My stable: rustc 1.47.0 (f3c7e066a 2020-08-28)
I'm using the latest master.

The fix on master also appears to leak memory.

from napi-rs.

Fixed test_module in this repo, but failed again in https://github.com/napi-rs/package-template/pull/86/files ....

from napi-rs.

Confirmed fixed by change CString::as_ptr() to CString::into_raw() in windows, which was considered to cause memory leak.

Seems like node will free the CString and cause double free if using as_ptr ?

from napi-rs.

wired, still failed in CI https://github.com/napi-rs/package-template/pull/86/checks

But in my windows virtual machine I was using [email protected] 32bit, I will try again tomorrow night.

from napi-rs.

After debugging, I found that attaching #[inline(never)] to check_status fixed the issue on my machine. This is definitely a rust codegen issue. That function is inlined incorrectly on that target.

Can you verify if this fixes things @Brooooooklyn?

from napi-rs.

@adumbidiot oh, let me have a try

from napi-rs.

Seems not work in CI https://github.com/napi-rs/package-template/pull/86/checks?check_run_id=1428438105

from napi-rs.

opt-level='s/z' seems not work on my computer, but opt-level=1 could work
See commits in napi-rs/package-template#95, opt-level = 1 worked fine, but failed both s and z

from napi-rs.

opt-level = 1 worked fine

Not work actually, just can execute require('index.node'), exit 3221225477 again while running tests

from napi-rs.

Seems like it could be resolved by change the codegen-units to 32 (or higher) and disable lto: https://github.com/napi-rs/package-template/pull/134/files#diff-b268bb7dc66e8638921e223098a11eabb92b424875ec72a19d6145dc1efbe3f2R90

from napi-rs.

Close in #1167

from napi-rs.