-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Switching to opt-level=z on i686-windows-msvc triggers STATUS_ACCESS_VIOLATION #67497
Comments
Tested on windows x86_64, no issues present |
napi-rs/napi-rs#297 same issue here |
As this is:
we're assigning |
Is this a regression in 1.48? Could you test on 1.47 and see if the same issue happens there? |
Tested 1.36.0 ~ 1.48.0, all these versions occurred this bug. |
It can reproduce in https://github.com/napi-rs/package-template
The reproduce step could be found here: https://github.com/napi-rs/package-template/blob/napi-1-pre/.github/workflows/CI.yaml#L189 You can also see Github actions output from napi-rs/package-template#86 |
And I found the error was from this function: https://github.com/napi-rs/napi-rs/blob/master/napi/src/js_values/mod.rs#L270 I add println into this function: #[repr(C)]
#[derive(Copy, Clone)]
pub struct napi_env__ {
_unused: [u8; 0],
}
/// Env ptr
pub type napi_env = *mut napi_env__;
#[repr(C)]
#[derive(Copy, Clone)]
pub struct napi_value__ {
_unused: [u8; 0],
}
/// JsValue ptr
pub type napi_value = *mut napi_value__;
#[derive(Clone, Copy)]
pub struct Value {
pub env: napi_env,
pub value: napi_value,
pub value_type: ValueType,
}
pub struct JsObject(pub(crate) Value);
impl JsObject {
#[inline]
pub fn create_named_method(&mut self, name: &str, function: Callback) -> Result<()> {
let mut js_function = ptr::null_mut();
let len = name.len();
let name = CString::new(name.as_bytes())?;
+ println!("{:p}", self.0.env);
check_status!(unsafe {
sys::napi_create_function(
self.0.env,
name.as_ptr(),
len,
Some(function),
ptr::null_mut(),
&mut js_function,
)
})?;
+ println!("{:p}", self.0.env);
check_status!(unsafe {
sys::napi_set_named_property(self.0.env, self.0.value, name.as_ptr(), js_function)
})
}
} The result was:
|
Is this line related to this issue? https://github.com/rust-lang/rust/blob/1.48.0/compiler/rustc_target/src/abi/call/mod.rs#L436 |
Fixed by set |
Still appears in my projects, change |
@pnkfelix does this one enough to be mcve? |
Visiting for P-high review @wesleywiser does this still occur? And, to answer the question above: It is rare for links to external repositories to qualify as truly minimal MCVEs. (And also, I've found in practice that links to external repositories run the risk of being deleted, so we really need some code in a spot we have ownership over before I'd be comfortable removing the needs-mcve label.) |
While investigating a completely unrelated issue on x86 (32-bit) QNX with @hexagonal-sun, we also got a crash with I think it might be related to this issue because on 32-bit x86 both QNX and Windows have a base stack alignment of 4 bytes instead of 16 on Linux. Note that the stack realignment shouldn't be necessary: since we pass We haven't fully narrowed down the cause yet, so this may still be a false lead, but it might be worth trying in this case. |
Here is a minimal example which reproduces the problem on Linux: https://github.com/hexagonal-sun/rust-alignment-error It uses a modified i585-unknown-linux-gnu target with the stack alignment set to 4 bytes instead of 16. Inline assembly in |
I've narrowed this down to what I think is an LLVM bug in the X86 backend. I've uploaded the reduced LLVM IR and assembly. For some reason LLVM is using an # %bb.5: # %bb3
[...]
pushl $4
popl %esi <-- esi = 4
[...]
leal 72(%esp), %eax <-- eax = esp + 72
orl %eax, %esi <-- eax = (esp + 72) | 4 If the stack is 8-byte aligned then this adds 4 to the pointer address, and everything works fine. However if the stack is offset by 4 bytes then this There is no reason for LLVM to generate an |
@Amanieu LLVM converts add to or if there are no common bits. That just means that something claims the low bits are known zero. I don't think the The stack alignment is decided by the subtarget and will always be 16 on Linux. It's possible to override it using the As such, I'm not sure your reduction here is meaningful (on Windows, codegen should be choosing stack alignment 4 for 32-bit x86). |
Adding
to your reduction does convert the orl into addl. |
Good point, I guess that was a false lead. |
I have a crate which compiles and tests fine, but as soon as I switch
opt-level=z
it triggersSTATUS_ACCESS_VIOLATION
in some tests, but only on the windows targets. Tested onThe corresponding log outputs can be found here https://ci.appveyor.com/project/dignifiedquire/deltachat-core-rust/builds/29699168
and the code deltachat/deltachat-core-rust#1087
I am sorry I don't have a more reduced testcase, but I am quite clueless on how to debug this tbh.
The text was updated successfully, but these errors were encountered: