Breaking the crt1.o -> atexit() -> malloc() dependency

Peter Jeremy peterjeremy at optushome.com.au
Thu Mar 6 02:06:23 PST 2008


On Thu, Mar 06, 2008 at 11:48:10AM +0200, Kostik Belousov wrote:
>On Wed, Mar 05, 2008 at 05:12:32PM -0800, Tim Kientzle wrote:
>> Here's a design that I think addresses all of the
>> issues people raised, including the POSIX requirement
>> that atexit() always be able to support 32 registrations.
>> It does it without using sbrk() or mmap(), either.

Looks good to me.

>I mostly agree with proposal, but there is also __cxa_atexit().

This is a special variant of atexit() and (as far as I can see)
can be treated in much the same way - allocate struct atexit_fn
and call atexit_register().

>And, besides the issue of the size of the static linked executables,
>there is more exposed problem of atexit() memory leaks. See
>http://lists.freebsd.org/pipermail/freebsd-stable/2008-February/040644.html

I believe that Tim's approach of maintaining a free list and checking
it on each atexit() call would handle this since the dlopen() will
implicitly invoke atexit() or equivalent.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20080306/15269448/attachment.pgp


More information about the freebsd-current mailing list