eclipse-iceoryx / eclipse-iceoryx/iceoryx
Lifetime issue when storing a `popo::Sample`
- Dominant language
- C++
- Stars
- 2.2k
- Forks
- 492
- Avg merge
- 18h 57m
- Merged PRs (30d)
- 1
Description
## Required information
**Operating system:**
Any
**Compiler version:**
Any
**Observed result or behaviour:**
Comes from this [comment](https://github.com/eclipse-iceoryx/iceoryx/pull/1355#discussion_r885483950):
> You have a livetime issue here. See this code:
>
>```
>SamplePointer&& acquireSample() {
> EventPublisher publisher;
> return std::move(publisher.Loan());
> }
>
> int main() {
> auto sample = acquireSample();
> }
> ```
>
> In the end you can construct a lot of examples where the EventPublisher goes out of scope before SamplePointer does and then one has a problem. I think this is another problem with the automotive API where one has to state at least a big red warning that the EventPublisher has to live as least as long as the SamplePointer.
>
> But just so that you are aware how bad this problem is, take a look at this evil bug:
>
> ```
> class MyClass {
> SamplePointer m_sample;
> EventPublisher m_publisher;
> }
> ```
>
> This ordering of member variables is evil, when the MyClass destructor destroys the member it does it in inverse order, first the m_publisher and then the m_sample and one has again undefined behavior. I would bet in a code review no one would have seen this.
There are a lot of bugs out there where applications cannot terminate cleanly and cause leaks or segfaults because of this issue.
>
**Expected result or behaviour:**
Add a notification in each of the destructors like it is done for `WaitSet` and `Listener`.
**Conditions where it occurred / Performed steps:**
See above
Contributor guide
Research direction
Start by examining the WaitSet and Listener destructors, which are cited as the existing pattern, then trace the SamplePointer and EventPublisher lifetime relationship in the shown examples. Identify each relevant destructor that needs a notification and add coverage for publisher/sample destruction order. Done means the lifetime hazard is detected consistently rather than causing undefined behavior, leaks, or termination failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100