-
Notifications
You must be signed in to change notification settings - Fork 422
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AddressSanitizer: new-delete-type-mismatch #2220
Comments
this can also happen with humble branch as well. |
Actually, I noticed this issue a long time ago while adding the zero_allocate.
The |
How about incorporating an additional size field at the beginning of the buffer to store the size value during buffer allocation? (NOTE: It results in a significant waste of memory when there are numerous small buffer allocations.) |
According to cppreference the ending parameter of both
So is there anyway to extract the size of the typename T given in
or a some way to find the type of the object that was allocated, or is that beyond the reach of the function. |
What if the type is It seems that using |
I stumbled on this issue, because I encountered problems when I wanted to use ROS2 >= humble with jemalloc. (Apparently I am not the first one: ROS 2 migration stories: The struggles of moving to Humble) I think I also think that
operator delete(void* ptr, std::size_t size) just calls operator delete(void* ptr) and ignores the size argument. Jemalloc instead explicitly implements a sized delete, which leads to memory errors when used together with rclcpp, because the size argument does not match the previously allocated size. So I wonder if there is a safe way to create an rcl_allocator_t struct from an STL allocator, because the STL allocator requires a size argument for deallocate .
|
I'm assuming that the C++ standard writers had a good reason to make the number of elements a parameter. Therefore, I would suggest to address this by adding a corresponding method which takes this as an argument. Further, we may want to consider deprecating the existing version of the function that does not have this argument. |
There are many errors related to this issue: |
Is this still an issue in Jazzy? Thanks. |
yes, this issue is still open. |
So what is required for this to be fixed? I am running into some issues and would like to be able to run our stack with these sanitisers. |
Bug report
Required Info:
rolling
Steps to reproduce issue
Expected behavior
No ASAN report generated.
Actual behavior
The following ASAN report generated.
AddressSanitizer: new-delete-type-mismatch
The text was updated successfully, but these errors were encountered: