serf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan Zhakov <>
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, <> wrote:
>> Author: ivan
>> Date: Thu Nov  5 07:40:58 2015
>> New Revision: 1712718
>> URL:
>> 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 <> 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

View raw message