update to use new memory_tools from osrf_testing_tools_cpp#101
update to use new memory_tools from osrf_testing_tools_cpp#101
Conversation
| '-D', 'rcutils_module_path=\"${rcutils_module_path}\"', \ | ||
| '${CMAKE_CURRENT_SOURCE_DIR}/resource/logging_macros.h.em' \ | ||
| ] \ | ||
| )") |
There was a problem hiding this comment.
@dhood I broke this line up because it was pretty long. It appears to work correctly, but if you'd prefer it not to be this way I can revert it.
|
@serge-nikulin fyi |
|
yes, I'm a subscriber. |
149e556 to
a823720
Compare
| return 5; | ||
| } | ||
| if (g_last_log_event.location->line_number != 65u) { | ||
| if (g_last_log_event.location->line_number != line_number) { |
There was a problem hiding this comment.
@dhood FYI I changed this too, does that seem ok to you?
|
I'm working on the issue on aarch64. |
|
these PRs are back in review right @wjwwood ? (other than the arm issue) |
|
Feel free to review but I’m still debugging the aarch64 issue. |
|
I've spent enough time on the And I'm going to disable memory tools on ARM for now. I'll put this in review again after I update our cmake to avoid doing memory tools on ARM, in addition to already avoiding it on Windows. |
|
@dejanpan, FYI |
|
@wjwwood ack. It is what it is. Review again tmr? |
dhood
left a comment
There was a problem hiding this comment.
overall looks good but I have some questions before approving
test/test_allocator.cpp
Outdated
| */ | ||
| TEST_F(CLASSNAME(TestAllocatorFixture, RMW_IMPLEMENTATION), test_default_allocator_normal) { | ||
| ASSERT_NO_MALLOC( | ||
| EXPECT_NO_MALLOC( |
There was a problem hiding this comment.
is there a default callback? if not, I think that since the callbacks have been removed above, this won't do anything if an unexpected malloc occurs? Maybe it should be wrapped in something like this?
There was a problem hiding this comment.
Looks like a bug. I should setup the callbacks before that.
test/test_time.cpp
Outdated
| on_unexpected_calloc([]() {FAIL() << "UNEXPECTED CALLOC";}); | ||
| on_unexpected_free([]() {FAIL() << "UNEXPECTED FREE";}); | ||
| enable_monitoring_in_all_threads(); | ||
| EXPECT_NO_MEMORY_OPERATIONS(;); |
There was a problem hiding this comment.
could you add a comment for what this is trying to ensure?
There was a problem hiding this comment.
Not sure, looks like a copy-paste typo. I'll remove it.
| using osrf_testing_tools_cpp::memory_tools::on_unexpected_calloc; | ||
| using osrf_testing_tools_cpp::memory_tools::on_unexpected_free; | ||
| using osrf_testing_tools_cpp::memory_tools::on_unexpected_malloc; | ||
| using osrf_testing_tools_cpp::memory_tools::on_unexpected_realloc; |
There was a problem hiding this comment.
it's a bit confusing to not see any usage of these in this file (I know they come from the EXPECT_NO_MEMORY_OPERATIONS macro).. I imagine there's a reason they either can't or shouldn't be embedded in the macro itself, but wanted to point out my concern (from a usability perspective) nonetheless
There was a problem hiding this comment.
I'll see if I can clean that up.
| set_on_unexpected_free_callback([]() {ASSERT_FALSE(true) << "UNEXPECTED FREE";}); | ||
| start_memory_checking(); | ||
| osrf_testing_tools_cpp::memory_tools::initialize(); | ||
| on_unexpected_malloc([]() {FAIL() << "UNEXPECTED MALLOC";}); |
There was a problem hiding this comment.
I know you probably had a reason for favouring the new name, but I did want to point out from a user perspective that set_*_callback seemed to better capture what this function was doing. Given the other macros e.g. EXPECT_NO_MEMORY_OPERATIONS taking in a set of statements to check, now when I look at something called on_unexpected_malloc I expect it to similarly be checking for unexpected malloc on a particular set of statements (which is not what it's doing). We can survive with the naming either way though, for sure.
There was a problem hiding this comment.
I was following the on_<event>(callback) style of things like JQuery, e.g. https://api.jquery.com/on/. Personally I find the new syntax easier to read, but that's subjective. I don't really follow:
I expect it to similarly be checking for unexpected malloc on a particular set of statements (which is not what it's doing).
Reading that, it's like on_unexpected_malloc(<statements>) becomes "on an unexpected malloc for statements <statements> do...?". It's an incomplete thought.
So I agree that set_*_callback is very unambiguous, but I don't exactly see the issue with on_*, and it's 9 characters shorter.
My personal preference would be to keep the new name, but I'm open to other arguments.
There was a problem hiding this comment.
Yeah, I don't mean that the function as it's named is exceptionally misleading, just that on first glance I expected that line to be doing checking for unexpected mallocs as opposed to setting a callback, whereas with the other naming it was clearer. If that's a naming pattern used by other languages e.g. jquery as you mentioned, then that's fine now that it's been changed
There was a problem hiding this comment.
on first glance I expected that line to be doing checking for unexpected mallocs as opposed to setting a callback
That's what I was talking about too, but the keyword on doesn't make sense to me without a callback, as-in on <something> do <this (callback)>, so I could imagine on taking statements and a callback, but not just statements. So maybe it's important to understand why on indicates to you (and potentially users) that something is being checked right there.
At any rate, it's documented:
|
I addressed the comments (I think, please have another look @dhood), here's new CI with |
|
as a note: I haven't reviewed the new code in the new repo |
|
@dhood that's fine. I think reviewing its usage here and having the tests pass will be good enough for now. Future changes can be reviewed in more detail. |
This is just a pr to use the new memory tools that I refactored out of this package and
rcltoo. After this will come a pr to make use of the memory tools in this repository more and fix memory allocation issues.