Skip to content
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

memory leak? Does this malloc ever get freed? #40

Closed
rotu opened this issue Sep 23, 2019 · 2 comments · Fixed by #41
Closed

memory leak? Does this malloc ever get freed? #40

rotu opened this issue Sep 23, 2019 · 2 comments · Fixed by #41

Comments

@rotu
Copy link
Collaborator

rotu commented Sep 23, 2019

x = reinterpret_cast<char *>(malloc(sz));

There’s a lot of other questionable code in here, including much use of macros where templates would be more appropriate and repeated code.

@eboasson
Copy link
Collaborator

@rotu you have sharp eyes! As long as the caller dutifully frees the memory all is well, but I never really looked into the details of how the result of deserialization is handled, other than in returning it to the caller of rmw_take. I simply followed the example Fast-RTPS's dynamic RMW code, assuming that it would get these details correct.

A little bit of digging now tells me that this particular case is never used! It is implemented in the eProsima Fast-CDR library with good reason — that's a generic tool for applications to build upon — but this particular use in TypeSupport_impl.h always uses the std::string case.

Deleting the char * case would be best.

There’s a lot of other questionable code in here, including much use of macros where templates would be more appropriate and repeated code.

I agree with that assessment. What I tried originally was classifying types as primitive or not, then have a single templatized one for all primitive ones and handling the few others with special cases, but I got lost in the C++ template error messages. Macros were simply the quickest way to getting something up and running. Now that times have changed, I'm all for cleaning this up.

The best thing would be to rewrite TypeSupport and serdes both. There is quite a bit of code involved in interpreting the ROS type description and some — I would suspect, common — types such as arrays of records of floats involve a significant bit of overhead now. It makes much more sense to preprocess the type to a simpler form that can be interpreted more efficiently.

@rotu
Copy link
Collaborator Author

rotu commented Sep 23, 2019

I agree that a rewrite is in order, and I’ll pitch in with a few PRs.

You may find (as I do) that Clang is tons better than gcc for writing template code. It gives clearer error messages.

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 a pull request may close this issue.

2 participants