serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <i...@apache.org>
Subject Re: svn commit: r1712718 - /serf/trunk/buckets/allocator.c
Date Thu, 05 Nov 2015 15:29:06 GMT
> On Thu, Nov 5, 2015 at 1:40 AM, <ivan@apache.org> wrote:
>
>> Author: ivan
>> Date: Thu Nov  5 07:40:58 2015
>> New Revision: 1712718
>>
>> URL: http://svn.apache.org/viewvc?rev=1712718&view=rev
>> Log:
>> Add another diagnostic macro SERF__DEBUG_USE_AFTER_FREE to detect usage of
>> bucket allocator after it destroyed by pool cleanup.
On 5 November 2015 at 16:31, Greg Stein <gstein@gmail.com> wrote:
> Seems this should be tried straight into the allocator debugging, rather
> than separately configurable. Use-after-free is quite bad, so I think it
> should always die right away.
>
Just to confirm that I'm understanding you properly: do you suggest to
enable this check by default and abort() on attempt to use bucket
allocator after it's destroyed?

> Your work on reporting unfreed items is a bit different, as some
> applications *may* choose to leave some allocations until the process exits.
>
I agree, but current documentation for serf_bucket_allocator_create()
says otherwise:
[[[
 * When the allocator is destroyed, if any allocations were not explicitly
 * returned (by calling serf_bucket_mem_free), then the @a unfreed callback
 * will be invoked for each block. @a unfreed_baton will be passed to the
 * callback.
 *
 * If @a unfreed is NULL, then the library will invoke the abort() stdlib
 * call. Any failure to return memory is a bug in the application, and an
 * abort can assist with determining what kinds of memory were not freed.
]]]

But any unfreed memory tracking will be expensive, so I'm not sure
that we're really going to implement documented behavior.

-- 
Ivan Zhakov

Mime
View raw message