-
Notifications
You must be signed in to change notification settings - Fork 43
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
Win32 API error in event open #458
Comments
@xxshady I can confirm the bug, also partially on Linux. It is actually two separate issues. The cause is If you adjust the code to this, the termination signal should be handled cleanly. // you need to add iceoryx2-bb-posix as dependency into your Cargo.toml
use iceoryx2_bb_posix::signal::*;
// ...
while !SignalHandler::termination_requested() {
match event_listener.blocking_wait_one() {
Ok(Some(id)) => println!("woke up {id:?}"),
Ok(None) => (),
Err(_) => break,
}
} So whenever you have a blocking call you need to register some kind of signal handler so that the application can cleanly terminate when CTRL+c is pressed. Another issue is, that we have introduced with v0.4. a stale resource cleanup when a node crashes or does not cleanup the resources. Then another node takes over and cleans the resources.
In your case this should happen as well but it seems there is a problem on Windows. |
@elfenpiff On Windows, when a node is started after an old iceoryx2 process was abruptly terminated, In the case that a node gets stuck due to this OpenFileMapping error, what can we do to clean up stale resources (other than manually removing files in |
@gyk Sadly, no, since we do not know what size they have or if they are currently used by something else. But I will look into this issue and can maybe provide a bug fix in the next few days. |
@gyk @xxshady I unraveled the issue with Windows. Shared Memory is not persistent in Windows. Whenever the last process that holds a shared memory handle terminates or crashes Windows removes the memory-mapped file from the file system. When a new process starts, it detects that there seems to exist the service but the dynamic segment of the service is missing - since the last process holding it crashed. So, it is correctly identified as corrupted, and the cleanup aborts here. |
…g no longer exists.
… shared memory is gone
…eanup [#458] corrupted services cleanup
@elfenpiff Testing with the
In the Is it expected behavior? |
@gyk No, it is not - thanks for the finding! It is a specialty in Windows, where we require shared memory state files. It slipped since process crashes are hard to test - especially on Windows. But it shouldn't be hard to fix - I will create another pull request and ping you when this is done. |
Not sure if it's a bug, probably somehow related to this?
Required information
Operating system: Windows 11, 23H2,
ver
:Microsoft Windows [Version 10.0.22631.4169]
Rust version: rustc 1.81.0 (eeb90cda1 2024-09-04)
Cargo version: cargo 1.81.0 (2dbb1af80 2024-08-20)
iceoryx2 version: 0.4.1
Detailed log output:
Details
Observed result or behaviour:
event notifier:
event listener:
Expected result or behaviour:
No error or at least more readable one?
Conditions where it occurred / Performed steps:
For the first time notifier and listener run correctly, the second time win32 errors occur (ctrl+c, cargo run again)
The text was updated successfully, but these errors were encountered: