[
https://issues.apache.org/jira/browse/DISPATCH-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk resolved DISPATCH-2039.
----------------------------------
Resolution: Fixed
> Memory pool should be manually poisoned so that ASAN works with it
> ------------------------------------------------------------------
>
> Key: DISPATCH-2039
> URL: https://issues.apache.org/jira/browse/DISPATCH-2039
> Project: Qpid Dispatch
> Issue Type: Wish
> Affects Versions: 1.15.0
> Reporter: Jiri Daněk
> Assignee: Jiri Daněk
> Priority: Minor
> Fix For: 1.17.0
>
>
> From https://github.com/google/sanitizers/wiki/AddressSanitizerManualPoisoning
> bq. A user may poison/unpoison a region of memory manually. Use this feature
> with caution. In many cases good old malloc+free is a better way to find heap
> bugs than using custom allocators with manual poisoning.
> As far as I can tell, it is nowadays not possible to turn off the pool
> allocation and use malloc/free, because the pool mechanism also implements
> the weak pointers and ref counters. That means giving hints to ASAN is the
> only way to discover memory bugs of the type (if what Chuck speculated is
> true) of DISPATCH-2032.
> bq. If you have a custom allocation arena, the typical workflow would be to
> poison the entire arena first, and then unpoison allocated chunks of memory
> leaving poisoned redzones between them. The allocated chunks should start
> with 8-aligned addresses.
> Alternatively, the current memory debugging machinery for the pool could take
> care of it on its own... but using ASAN seems sensible to me.
> http://blog.hostilefork.com/poison-memory-without-asan/
> h3. Nice to have extra features (which won't be implemented at first)
> * redzones, there should be chunks of poison on either end of a returned
> memory, to detect invalid accesses out of bounds; this means deliberate waste
> of memory (I am thinking 3x increase, to make implementation easy)
> * quarantine, returned chunks should be kept in the pool for some time before
> they are returned as new allocations, to catch use-after-free; this policy
> goes against performance considerations
> h3. Open issues
> Is it necessary to lock around the poison macros? I did not understand the
> thread safety note in API comment fully.
> h3. One thought
> Actually, setting a limit on free_list length == 0 would effectively disable
> pool and turn the calls into simple wrappers over malloc/free. It would be
> enough to make this configurable at build time. Then asan should work just
> fine without poison.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
