Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on Sep 1, 2022. It is now read-only.

Conversation

@neilstephens
Copy link
Contributor

There was a race condition on shutdown.
If link timer handlers were queued for execution (with success error code),
LinkContext could be destroyed in the meantime and handlers would access freed memory.

This fix blocks destruction if handlers are outstanding, and handler check isOnline

There was a race condition on shutdown.
If link timer handlers were queued for execution (with success error code),
LinkContext could be destroyed in the meantime and handlers would access freed memory.

This fix blocks destruction if handlers are outstanding, and handler check isOnline
@jadamcrain
Copy link
Member

jadamcrain commented Oct 1, 2020

I think we definitely want to fix this, but not by idling in a destructor. We'll keep the PR open though until we have a different fix.

These kinds of issues with Async C++ are getting pretty tiresome now that we're basing all our new tech on Rust with async/await.

@neilstephens
Copy link
Contributor Author

Yep, the PR was more to illustrate the problem and work as a band-aid for my fork. Fixing the root cause was a bit beyond me. I'll stay tuned, thanks.

Rust Async sounds really cool btw. I'm definitely tired of dealing with lifetime issues in C++ async

@jadamcrain
Copy link
Member

Yeah, async is really hard to get right. Rust makes it trivial.

We have Modbus and DNP3 implemenation (with bindings for C, Java, and .NET Core) under development if you're interested in how it works:

https://github.com/stepfunc/

@emgre
Copy link
Member

emgre commented Nov 17, 2020

@neilstephens Can you try #407 and see if the issue was properly resolved? I went with a slightly different approach than your original PR.

@neilstephens
Copy link
Contributor Author

Gday @emgre,

I haven't tested it yet (but I will give it a go when I get a chance), but I don't think #407 actually fixes the race. It probably shrinks the probability of hitting it, but the link context could still get destroyed right after the weak ptr check... right?

Cheers,
Neil.

@emgre
Copy link
Member

emgre commented Nov 18, 2020

@neilstephens I don't think there's a race condition here. Everything (including the timer) is executed in an ASIO strand, which guarantees sequential execution. From my understanding, the issue was that the callback captured this and could be executed after the destruction of LinkContext if the callback was in the ASIO event queue.

@neilstephens
Copy link
Contributor Author

@emgre , The only thing that isn't executed on the strand is the destruction of the LinkContext. That's why there was the race in the first place. The problem wasn't that the handlers were executed after, but during, the destruction of the LinkContext. Cheers.

@neilstephens neilstephens deleted the branch dnp3:develop October 22, 2021 06:31
@neilstephens neilstephens deleted the develop branch October 22, 2021 06:31
@neilstephens
Copy link
Contributor Author

Replaced with #435
@emgre , I took your approach (#407) of copying a weak_ptr into the callbacks, but instead using a member of LinkContext (that could still be in the process of destructing), I use the LinkSession which actually owns the lifetime of the LinkContext and is already managed by a shared pointer. see #435 for details.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants