[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