[
https://issues.apache.org/jira/browse/DISPATCH-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17340879#comment-17340879
]
ASF subversion and git services commented on DISPATCH-2039:
-----------------------------------------------------------
Commit 4663aad44243295ae9e166475d905f74a4e5a896 in qpid-dispatch's branch
refs/heads/main from Jiri Daněk
[ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=4663aad ]
DISPATCH-2039 Poison the memory pool so that ASAN works better with it (#1118)
When there is a read or write to the poisoned area, the error message looks like
```
==15792==ERROR: AddressSanitizer: use-after-poison on address 0x611000034dd8 at
pc 0x7fdaa75fc713 bp 0x7fff2d0c8d80 sp 0x7fff2d0c8d78
14: WRITE of size 8 at 0x611000034dd8 thread T0
14: #0 0x7fdaa75fc712 in qd_hash_internal_remove_item
/home/jdanek/repos/qpid/qpid-dispatch/cmake-build-debug-asan/../src/hash.c:131:30
14: #1 0x7fdaa75fb51d in qd_hash_free
/home/jdanek/repos/qpid/qpid-dispatch/cmake-build-debug-asan/../src/hash.c:146:13
[...]
```
> 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
> Priority: Minor
>
> 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]
