bug-readline
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-readline] unfreed memory allocated within rl_initialize


From: John Darrington
Subject: Re: [Bug-readline] unfreed memory allocated within rl_initialize
Date: Fri, 28 Nov 2014 22:22:33 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Nov 28, 2014 at 03:51:56PM -0500, Chet Ramey wrote:
     On 11/27/14 1:25 PM, Andreas Grapentin wrote:
     
     > valgrind will probably claim that these blocks are still reachable at
     > program exit, but that is beside the point. I am not claiming that
     > readline leaks memory, I claim that the unfreed allocations at exit
     > produce noise that makes it harder to find real memory leaks.
     
     I think it's easy enough to tell the difference between memory that
     valgrind reports as leaked and blocks it reports as still reachable.
     I've used valgrind pretty extensively and I've never had that trouble.

Strange!  I have it all the time.

For any non-trivial case valgrind will report many blocks as "Possibly lost".
These are blocks which valgrind cannot tell if they are lost or not, because a
"still reachable" block is obscuring its view.
     
     > IMO, it would be nice to have a rl_finalize() function, that explicitly
     > releases the resources held by the library.
     
     If someone wants to take a shot at writing one, I'd be happy to look
     at it.

Some developers object to implementing such a features for reason of speed.
Most libraries have a "gc-friendly" setting which clears up these resources if 
set.

J'

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]