FIX proposal for a crash that happens because of some misuse of const_cast<> #1920
Conversation
ACE::writev_n with iovecs that have been allocated on the heap. In case of a partial send, libACE will loop until all the data has been sent. The problem is that it updates its arguments when doing so, leaving the caller with one or more updated pointers inside the table of iovecs. Attempting to free such a pointer results in a fault (the value can even not be aligned properly). The fix simply copies the iovec data _if necessary_ (no perf penalty otherwise), and updates those values instead of the arguments.
|
Hello, |
|
What is exactly copied, only the iovec array but not the application data it refers to, correct? Any idea to extend one of the existing ACE unit tests as reproducer? |
|
Hello, |
|
Hello, |
WalkthroughThis change modifies the Changes
Sequence Diagram(s)sequenceDiagram
participant Caller
participant ACE_Function as ACE::sendv_n_i / writev_n
participant Shadow as Shadow Copy Manager
Caller->>ACE_Function: Call function with const iovec array
alt Modification Needed
ACE_Function->>Shadow: Allocate & copy iovec array
ACE_Function->>Shadow: Update shadow copy fields
else No Modification
Note right of ACE_Function: Use original iovec directly
end
ACE_Function->>Caller: Return result and cleanup shadow copy if allocated
Poem
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
ACE/ace/ACE.cpp (3)
1870-1876: Reinitialize localiovpointer with const correctness
Similar to the previous segment, this preserves the originaliovec. Consider extracting this repeated pattern into a helper function for maintainability.
1922-1938: On-demand allocation block repeated
This block duplicates the earlier logic for partial sends. A unified helper method could reduce duplication and simplify future maintenance.
2242-2258: Repeats the shadow copy memory allocation logic
This third repetition further highlights a refactoring opportunity to centralize the partial-send logic.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
ACE/ace/ACE.cpp(6 hunks)
🔇 Additional comments (8)
ACE/ace/ACE.cpp (8)
1768-1774: Preserve originaliovecto prevent unintended pointer mutations
This approach to storingiin a localiovpointer while keeping itconstis a clean way to ensure the original array isn't modified unless needed.
1816-1838: Allocate shadow copy on-demand to handle partial sends
Allocating theshadow_iovecarray only when partial data remains is a good strategy to avoid unnecessary overhead. The null check ensures this allocation happens exactly once.
1842-1850: Properly free shadow copy to avoid memory leaks
The conditional deallocation ofshadow_iovecprevents leaks and keeps memory usage in check.
1940-1944: Pointer arithmetic on the shadow copy
Ensuring that the base pointer is updated on the shadow array (rather than the original) is key to preventing alignment and ownership issues. Looks solid.
1948-1956: Cleanup of dynamically allocated shadow iovec
This cleanup mirrors the earlier pattern, preventing resource leaks. The coherency is appreciated.
2213-2219: Maintains const correctness of user-suppliediovec
Again, using a localiovpointer helps enforce the “no modification unless needed” rule. This design is well-aligned with the updated function contract.
2260-2264: Shadow pointer arithmetic remains correct
Adjusting theiov_baseandiov_lenon the shadow array rather than modifying the caller’s iovec is consistent with preventing error-prone pointer updates.
2268-2276: Release shadow copy if allocated
Properly freeing theshadow_iovecresources ensures no leaks in this partial-send scenario.
Hello,
First of all, thank you for providing libACE.
This commit is a proposal to fix a crash that can happen with
ACE::sendv_n_i()andACE::writev_n(), in case the giveniovecshave been allocated on the heap.Indeed in case of a partial send, libACE will loop until all the data has been sent. The problem is that it updates its arguments when doing so, leaving the caller with one or more updated pointers inside the table of iovecs. Attempting to free such a pointer results in a fault (the value can even not be aligned properly anymore).
The fix simply copies the iovec data if necessary (no perf penalty otherwise), and updates those values instead of the arguments.
Thank you.
Summary by CodeRabbit
These enhancements improve overall reliability and efficiency of data transfer processes, providing a smoother and more predictable experience for users.