eclipse-iceoryx / eclipse-iceoryx/iceoryx

Lifetime issue when storing a `popo::Sample`

Open
#1,378 1 comment 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.