You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Jiri Daněk (Jira)" <ji...@apache.org> on 2021/04/06 21:06:00 UTC
[jira] [Updated] (DISPATCH-2039) Memory pool should be manually
poisoned so that ASAN works with them
[ https://issues.apache.org/jira/browse/DISPATCH-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jiri Daněk updated DISPATCH-2039:
---------------------------------
Description:
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. 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.
was:
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 of the pool allocation and use malloc/free, because the pool mechanism also implements the weak pointers. 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.
> Memory pool should be manually poisoned so that ASAN works with them
> --------------------------------------------------------------------
>
> 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. 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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org