On Thu, Jan 26, 2017 at 8:48 AM, Dario Lombardo
<dario.lombardo.ml@xxxxxxxxx> wrote:
> On Thu, Jan 26, 2017 at 2:11 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>> - your code will fail any time wmem chooses a different allocator
>> (this happens in CI, and occasionally elsewhere as well)
>>
>
> I don't get this. Can you explain it a little bit?
wmem ships with four different allocator algorithms (see
wmem_allocator_type in wmem_core.h) of which the block allocator you
are looking at is only one. When a wmem scope is initialized the
backing algorithm can be overridden by an environment variable (see
wmem_init() and wmem_allocator_new() in wmem_core.c). This is mostly
useful on the build machines to turn on additional safety checks (the
strict allocator) or to be friendly to memory analyzers like valgrind
(the simple allocator). However, anyone can use it.
If the allocator is overridden then your cast
`(wmem_block_allocator_t*)allocator->private_data` will be invalid and
the remainder of the function will probably blow up somewhere.
> Yes. Basically I'd like the idea to give the user a very useful error message. The wmem is pretty hard to debug, since a wrong scope basically means a segment violation, a double free, or so. But that can happen very far from where the error is.
You should actually be able to use the wmem scope override for this.
Force the allocator to be strict (run with
WIRESHARK_DEBUG_WMEM_OVERRIDE=strict) and it should fail immediately
at the point of the bug.
