You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is mainly about the implementation code and its possible risk.
In implementation/endpoints/src/tcp_server_endpoint_impl.cpp:93, where the implementation of tcp_server_endpoint_impl::start() locates.
The variable new_connection is declared as a shared_ptr to automatically release its memory resource when it runs out of the scope. This approach is correct in the case of synchronous operation, since the callee function acceptor() would always finish BEFORE the caller function tcp_server_endpoint_impl::start() finishes. But it could lead to possible dangling pointer problem in the case of asynchronous operation, since the accept() and accept_cbk() function could be actually called AFTER tcp_server_endpoint_impl::start() finishes, when new_connection has been ALREADY RELEASED.
Should consider change the first parameter of accept_cbk() from const connection::ptr & to connection::ptr&& and correspondingly change the caller argument to std::move(new_connection).
Reproduction Steps
No response
Expected behaviour
Dangling pointer. It could lead to all kinds of undefined behaviors.
Logs and Screenshots
No response
The text was updated successfully, but these errors were encountered:
StalinCCCP
changed the title
[BUG]: Possible dangling pointer in case of asynchronous network I/O operation
[BUG]: Possible dangling pointer in the case of asynchronous network I/O operation
May 7, 2024
vSomeip Version
v3.4.10
Boost Version
1.74
Environment
Ubuntu 22.04
Describe the bug
This issue is mainly about the implementation code and its possible risk.
In implementation/endpoints/src/tcp_server_endpoint_impl.cpp:93, where the implementation of tcp_server_endpoint_impl::start() locates.
The variable new_connection is declared as a shared_ptr to automatically release its memory resource when it runs out of the scope. This approach is correct in the case of synchronous operation, since the callee function acceptor() would always finish BEFORE the caller function tcp_server_endpoint_impl::start() finishes. But it could lead to possible dangling pointer problem in the case of asynchronous operation, since the accept() and accept_cbk() function could be actually called AFTER tcp_server_endpoint_impl::start() finishes, when new_connection has been ALREADY RELEASED.
Should consider change the first parameter of accept_cbk() from const connection::ptr & to connection::ptr&& and correspondingly change the caller argument to std::move(new_connection).
Reproduction Steps
No response
Expected behaviour
Dangling pointer. It could lead to all kinds of undefined behaviors.
Logs and Screenshots
No response
The text was updated successfully, but these errors were encountered: