[
https://issues.apache.org/jira/browse/TS-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13096996#comment-13096996
]
Leif Hedstrom commented on TS-567:
----------------------------------
ats_malloc() has a scary comment:
{code}
/*
* There's some nasty code in libts that expects
* a MALLOC of a zero-sized item to wotk properly. Rather
* than allocate any space, we simply return a NULL to make
* certain they die quickly & don't trash things.
*/
{code}
This is bad, we ought to fix this, because I'd really like for ats_malloc() to
bail out (exit) if it fails to allocate things. But, with the above, it means
ats_malloc could return a NULL pointer under certain conditions, which I'm not
sure is a good idea or not.
> Cleanup of memory allocation in libinktomi++
> --------------------------------------------
>
> Key: TS-567
> URL: https://issues.apache.org/jira/browse/TS-567
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core
> Reporter: Leif Hedstrom
> Assignee: Leif Hedstrom
> Priority: Critical
> Fix For: 3.1.1
>
> Attachments: clear_memory.patch, malloc.txt
>
>
> There's a lot of ifdef's and debugging code paths around various allocation
> schemes in libinktomi++. We should clean this up, and simplify. It'd also be
> great to make it easy to enable various other allocators, e.g. jemalloc or
> tcmalloc, as part of the build system, causing ink_malloc / xmalloc and STL
> containers to use the new allocator. In particular for STL containers, it
> means we might need to have some allocator setup / initialization?
> Also, when should we use ink_malloc() vs xmalloc() ? It's quite
> inconsistently used right now I think. And, there are a few places using
> malloc() (etc.) directly, which we ought to fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
