Wireshark mailing list archives
Re: [PATCH] Re: Freeing memory of se_alloc'ated object
From: Max <dmitrmax () gmail com>
Date: Tue, 3 May 2011 00:59:48 +0400
2011/5/2 <darkjames-ws () darkjames pl>:
On Mon, May 02, 2011 at 02:12:39AM +0400, Max wrote:it costs one additional pointer per each memory chunk allocated.Actually why dtor member is inside emem_chunk_t struct? and not inside emem_header_t? :>
Because there are two modes the memory pool can work with. One that uses emem_alloc_glib() - it allocates one emem_chunk_t each time you call *e_allloc(). It uses emem_header_t only to chain these chunks for deallocation. Thus for each allocation we need a space to store the pointer to the destructor. That is why I choosed the emem_chunk_t - it is the most obvious. The second mode that uses emem_alloc_chunk() allocates big chunks on per demand basis and then breaks this chunk into small allocations. But destructor in this case can be called (or not) for every allocation. So the space (if needed) to store the destructor pointer is allocated within each allocation in very similar way like the canaries do. In that case I use pointer in emem_chunk_t to refer the last destructor in chain.
I would gladly read you comments, critics and suggestions regarding this patch.It seems that you put dtor data before canary, and you execute dtors before checking one. Buffer overflows can lead to executing code from given pointer.
Frankly speaking, I don't know how canaries work but suppose you are right. I can change the order if you are sure that order matters.
About API I'd prefer smth like: se_register_gc_dtor(void *ptr, emem_dtor_cb dtor) which would register already allocated ptr. (+) It'd work with any se_* allocated memory. (+) you can register it any time (not only at allocation) (-) you should check if ptr is valid pointer (se_verify_pointer())
Can you provide a usecase for such an API? Are you sure that you really often decide during runtime whether you need destructor or not? :))) -- Max ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Freeing memory of se_alloc'ated object Max (May 01)
- Re: Freeing memory of se_alloc'ated object Guy Harris (May 01)
- Re: Freeing memory of se_alloc'ated object Max (May 01)
- Re: Freeing memory of se_alloc'ated object Guy Harris (May 01)
- [PATCH] Re: Freeing memory of se_alloc'ated object Max (May 01)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object darkjames-ws (May 02)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Max (May 02)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Jakub Zawadzki (May 03)
- Re: Freeing memory of se_alloc'ated object Max (May 01)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Jeff Morriss (May 02)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Guy Harris (May 02)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Max (May 02)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object ronnie sahlberg (May 02)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Max Dmitrichenko (May 02)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Stephen Fisher (May 03)
- Re: Freeing memory of se_alloc'ated object Guy Harris (May 01)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Jeff Morriss (May 03)
- Re: [PATCH] Re: Freeing memory of se_alloc'ated object Max (May 02)