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

the memory occupied by the program is getting larger and larger #86

Closed
Teemoshan opened this issue Jul 21, 2020 · 10 comments
Closed

the memory occupied by the program is getting larger and larger #86

Teemoshan opened this issue Jul 21, 2020 · 10 comments
Labels
bug Something isn't working debugging Might be a bug, looking into the issue

Comments

@Teemoshan
Copy link

9ABF6A4447E8CA7AC763608040E13657
Hi, I encountered some problems in the process of using, the memory occupied by the program is getting larger and larger, as shown in the picture, MSCKF-VIO does not have this problem.

@goldbattle
Copy link
Member

goldbattle commented Jul 21, 2020 via email

@Teemoshan
Copy link
Author

33B5FC6FEE4AF16FFA8FB0663166CDBA
the ros subscriber node also takes up a lot of memory

@Teemoshan
Copy link
Author

When max_cameras is 1, the program is normal. But when I use two camera , the memory occupied by the program is getting larger. This also happens on the euroc dataset, you can also try.

@goldbattle goldbattle added the bug Something isn't working label Jul 22, 2020
@goldbattle
Copy link
Member

Yeah this isn't something that should be happening. Maybe something to do with visualization or how multicam tracks are handled. I will try to take a look and see if I can see anything.

@Teemoshan
Copy link
Author

Have you solved this problem? @goldbattle

@goldbattle
Copy link
Member

I have not due to time constraints, hopefully I will soon, but if you have any further investigations feel free to post, thanks!

@kimyoungji
Copy link

@goldbattle

I found that this is caused by line 151-159 in 'TrackKLT::feed_stereo'.
This code is about building optical flow pyramids using cv functions and threads.
I don't know the exact reasons why using threads arouses memory leak, it was fine when I revise it as
cv::buildOpticalFlowPyramid(img_left, imgpyr_left, win_size, pyr_levels);
cv::buildOpticalFlowPyramid(img_right, imgpyr_right, win_size, pyr_levels);
I hope this will be helpful for your upcoming updates.
Thanks!

@goldbattle
Copy link
Member

Hi, I wasn't able to reproduce this on my side.
What version of OpenCV are you using @Teemoshan and @kimyoungji ?

@goldbattle goldbattle added the debugging Might be a bug, looking into the issue label Sep 30, 2020
@kimyoungji
Copy link

Mine is opencv 3.3.1.

@goldbattle
Copy link
Member

This should be addressed in #117, valgrind doesn't report any memory leaks and we are switched over to smart points.
This might be specific to an OpenCV version, try upgrading if it is still an issue or use your above fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working debugging Might be a bug, looking into the issue
Projects
None yet
Development

No branches or pull requests

3 participants