[libcamera-devel] [PATCH 1/4] cam: free allocated buffers when done capturing
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Mon Feb 25 09:43:57 CET 2019
Hi Niklas,
On Sun, Feb 24, 2019 at 05:59:54PM +0100, Niklas Söderlund wrote:
> On 2019-02-22 02:34:24 +0200, Laurent Pinchart wrote:
> > On Wed, Feb 20, 2019 at 03:37:33PM +0100, Niklas Söderlund wrote:
> >> The allocated buffers needs to be freed once the application is done
> >> with them.
> >>
> >> Signed-off-by: Niklas Söderlund <niklas.soderlund at ragnatech.se>
> >
> > Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>
> Thanks.
>
> > Does this fix valgrind warnings ?
>
> Unfortunately not, more work is needed to fix this. Running cam with the
> --capture option using the UVC pipeline on master.
>
> ==9051== HEAP SUMMARY:
> ==9051== in use at exit: 800 bytes in 16 blocks
> ==9051== total heap usage: 572 allocs, 556 frees, 278,788 bytes
> allocated
> ==9051== ==9051== LEAK SUMMARY:
> ==9051== definitely lost: 448 bytes in 4 blocks
> ==9051== indirectly lost: 352 bytes in 12 blocks
> ==9051== possibly lost: 0 bytes in 0 blocks
> ==9051== still reachable: 0 bytes in 0 blocks
> ==9051== suppressed: 0 bytes in 0 blocks
>
> With this series applied.
>
> ==9212== HEAP SUMMARY:
> ==9212== in use at exit: 800 bytes in 16 blocks
> ==9212== total heap usage: 587 allocs, 571 frees, 281,271 bytes
> allocated
> ==9212== ==9212== LEAK SUMMARY:
> ==9212== definitely lost: 448 bytes in 4 blocks
> ==9212== indirectly lost: 352 bytes in 12 blocks
> ==9212== possibly lost: 0 bytes in 0 blocks
> ==9212== still reachable: 0 bytes in 0 blocks
> ==9212== suppressed: 0 bytes in 0 blocks
>
> More work is needed to track down the last leeks, I'm tracking this and
> hope to get to the bottom of this. All I know at the moment is that the
> leaks happen in the capture call path on UVC. Need to try other
> pipelines once I'm home and have access to the IPU3.
valgrind should give you a more detailed list of leaks if you specify a
few extra options I can't remember right now :-) It should tell you what
those options are when you run it though. There are two leaks related to
libudev that I believe are not our fault, apart from that the rest
should be fixed.
> >> ---
> >> src/cam/main.cpp | 10 +++++++---
> >> 1 file changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/src/cam/main.cpp b/src/cam/main.cpp
> >> index 9b67ab75a6a1663e..b034eb25429abeb3 100644
> >> --- a/src/cam/main.cpp
> >> +++ b/src/cam/main.cpp
> >> @@ -163,7 +163,8 @@ static int capture()
> >> Request *request = camera->createRequest();
> >> if (!request) {
> >> std::cerr << "Can't create request" << std::endl;
> >> - return -ENOMEM;
> >> + ret = -ENOMEM;
> >> + goto out;
> >> }
> >>
> >> std::map<Stream *, Buffer *> map;
> >> @@ -171,13 +172,13 @@ static int capture()
> >> ret = request->setBuffers(map);
> >> if (ret < 0) {
> >> std::cerr << "Can't set buffers for request" << std::endl;
> >> - return ret;
> >> + goto out;
> >> }
> >>
> >> ret = camera->queueRequest(request);
> >> if (ret < 0) {
> >> std::cerr << "Can't queue request" << std::endl;
> >> - return ret;
> >> + goto out;
> >> }
> >> }
> >>
> >> @@ -187,6 +188,9 @@ static int capture()
> >> ret = loop->exec();
> >>
> >> camera->stop();
> >> +out:
> >> + camera->freeBuffers();
> >> +
> >> return ret;
> >> }
> >>
--
Regards,
Laurent Pinchart
More information about the libcamera-devel
mailing list