eclipse-iceoryx / iceoryx2

Eclipse iceoryx2™ - true zero-copy inter-process-communication in pure Rust
https://iceoryx.io
Apache License 2.0
1.03k stars 40 forks source link

[bug] payload_ptr_from_header doesn't work as expected #441

Closed xieyuschen closed 1 month ago

xieyuschen commented 1 month ago

see https://github.com/eclipse-iceoryx/iceoryx2/pull/440, you can run :

cargo test --package iceoryx2 --lib -- 

service::static_config::message_type_details::tests::test_payload_ptr_from_header --exact 

I use linux when I devloped the iceoryx2.

➜  iceoryx2 git:(report-bug) ✗ uname -a
Linux xieyuschen 5.15.0-48-generic #54~20.04.1-Ubuntu SMP Thu Sep 1 
16:17:26 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

I think something goes wrong during retrieve the payload pointer. I will delve it on Monday and just reported it first. It's found when I tried to add some test cases in #439 so I have separated the normal test and the abnormal in different PRs.

I got the failure: listed below:

running 1 test
test service::static_config::message_type_details::tests::test_payload_ptr_from_header ... FAILED

failures:

---- service::static_config::message_type_details::tests::test_payload_ptr_from_header stdout ----
thread 'service::static_config::message_type_details::tests::test_payload_ptr_from_header' panicked at iceoryx2/src/service/static_config/message_type_details.rs:147:9:
assertion failed: expr: got == 9999;  value: 1 == 9999
stack backtrace:
   0: rust_begin_unwind
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/panicking.rs:74:14
   2: iceoryx2::service::static_config::message_type_details::tests::test_payload_ptr_from_header
             at ./src/service/static_config/message_type_details.rs:147:9
   3: iceoryx2::service::static_config::message_type_details::tests::test_payload_ptr_from_header::{{closure}}
             at ./src/service/static_config/message_type_details.rs:130:38
   4: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
   5: core::ops::function::FnOnce::call_once
             at /rustc/eeb90cda1969383f56a2637cbd3037bdf598841c/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

failures:
    service::static_config::message_type_details::tests::test_payload_ptr_from_header
xieyuschen commented 1 month ago

closed it as it could be solved by adding #[repr(C)]. i'm trying to understand whether we have a way to force users add it for their structures. Thanks again, i have missed this part before.

elBoberido commented 1 month ago

@xieyuschen we are planning to have a proc macro which would add #[repr(C)] or at least check for it. It would also implement a trait if it can ensure the the type is shared memory compatible.