-
Notifications
You must be signed in to change notification settings - Fork 434
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. |
Does anybody have a workaround for this problem? We're having some memory issues in one of our executables and I have a strong suspicion that the cause might be this bug. We're not using any custom allocators in our project so I would be okay even with replacing the body of the retyped_* functions with malloc/free/realloc. |
We work around it by changing
#if 0 Which should have the exact same effect as changing the implementation of the |
@kfabian This is still a problem on Linux though. I am getting the error as soon as a C++ node registers.
Am I reading rclcpp/rclcpp/include/rclcpp/allocator/allocator_common.hpp correct in that it assumes that allocations are always of size 1? In glibc malloc throws away this information, but when using the address sanitizer or jemalloc or tcmalloc this results in issues? |
You are not referring to the workaround to always use the result of
Basically yes. Not glibc malloc throws away the size, but the libcstc++ implementation of A proper solution might be to change the signature of the |
Using I think this should at least have a ton of warnings in the allocator template tutorial that the size of the deallocation may not be accurate. Would you support a PR which added those changes? |
That is the reason why this problem only occurs if a malloc implementation like jemalloc or tcmalloc override
I think in practice it would be possible to provide the size to |
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: