Skip to content

fix: Use default rcl allocator if allocator is std::allocator#3058

Open
jmachowinski wants to merge 2 commits intoros2:rollingfrom
cellumation:alloc_try2
Open

fix: Use default rcl allocator if allocator is std::allocator#3058
jmachowinski wants to merge 2 commits intoros2:rollingfrom
cellumation:alloc_try2

Conversation

@jmachowinski
Copy link
Collaborator

@jmachowinski jmachowinski commented Feb 11, 2026

This fixes a bunch of warnings if using ASAN / valgrind on newer OS versions. It also fixed a real bug, as giving the wrong size on deallocate is undefined behavior according to the C++ standard.

This version of the patch keeps the behavior for users that specified an own allocator the same and in therefore back portable.

Alternative to #3054

USED AI:
Yes, chatgpt to generate the template methods to check for the existence of a method on a class in c++17.

Copy link
Collaborator

@fujitatomoya fujitatomoya left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jmachowinski thanks for fixing this issue. (it's been a looooong time... 😓 )

the approach looks good to me. a couple of things.

  • you happened to miss the DCO.
  • a few deprecated warning (which are added by this PR) detected on else where.

btw, the custom allocator path is still left broken? i think this PR explicitly leaves the retyped_allocate/retyped_deallocate bugs in place for non-std::allocator users. it means users with custom allocators will still hit the same ASAN/valgrind issues. It would be worth a comment or deprecation warning on the non-default path as well?

@jmachowinski
Copy link
Collaborator Author

@fujitatomoya This is the 'tick' version of this patch. It is also a first draft version (which I should have written in the pr...) as I did not wont to polish it if the patch got turned down again.

#3054 was discussed in the last PMC meeting and was turned down for two reasons :

  • API removal without tick / tock
  • Silent breakage for users using custom allocators.

The big drawback of #3054 was that users of custom allocators would silently fall back to malloc / free for everything happening in rcl.

I am not planning on fixing the code path for custom allocators, as the plan is to remove it altogether after the next release. I will mark it as deprecated though.

Janosch Machowinski and others added 2 commits February 13, 2026 20:05
This fixes a bunch of warnings if using ASAN / valgrind on newer
OS versions. It also fixed a real bug, as giving the wrong size
on deallocate is undefined behavior according to the C++ standard.

This version of the patch keeps the behavior for users that
specified an own allocator the same and in therefore back portable.

Signed-off-by: Janosch Machowinski <J.Machowinski@cellumation.com>
This commit adds the feature, that the user can now specify a method
rcl_allocator_t get_rcl_allocator() on the given allocator. This method
will be called if present, to get the rcl allocator.
If the method is not present, the code will fall back to the old
(and faulty) implementation and show a deprecation warning.

Signed-off-by: Janosch Machowinski <J.Machowinski@cellumation.com>
@jmachowinski
Copy link
Collaborator Author

Pulls: #3058
Gist: https://gist.githubusercontent.com/jmachowinski/f83bdbf7ac4ed3ce666e9721d0d1b996/raw/ae29de5029a9a2e6489b67f66710e870a9bed430/ros2.repos
BUILD args:
TEST args:
ROS Distro: rolling
Job: ci_launcher
ci_launcher ran: https://ci.ros2.org/job/ci_launcher/18201

  • Linux Build Status
  • Linux-aarch64 Build Status
  • Linux-rhel Build Status
  • Windows Build Status

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants