[Xenomai] heap corruption with multiple, differently-sized calls to rt_queue_alloc()

Philippe Gerum rpm at xenomai.org
Sun Mar 5 15:59:50 CET 2017

On 03/05/2017 12:43 PM, Philippe Gerum wrote:
> On 03/04/2017 03:30 AM, Josh Bowman wrote:
>> Hi,
>> I'm having a problem when trying to allocate multiple blocks using
>> rt_queue_alloc(). When my client code is building a message to send to
>> queue, it sometimes finds that it needs a bigger block. So it creates a new
>> block via rt_queue_alloc(); copies the data from the previous block into
>> the new block; and then calls rt_queue_free() on the old block.
>> The code included here is a simplified version of this process. It
>> allocates a buffer; puts some data in it; allocates a new buffer; and then
>> checks to make sure the previous buffer is intact. Then it frees the
>> previous buffer and loops.
>> When I run this code, it prints:
>> ERROR: at 7, 2: after rt_queue_alloc, checkMessage failed at loc 480
>> This means the buffer previously returned by rt_queue_alloc() is damaged by
>> the next call to rt_queue_alloc().  I set a watch in the debugger, and it
>> looks like the damage is done at line 376 of lib/alchemy/queue.c; this
>> seems to indicate the heapobj_alloc() is returning a region that overlaps
>> the one previously allocated.
>> I'm running Xenomai/mercury from stable-3.0.x on x86_64, with config:
>> "--with-core=mercury --enable-smp --enable-pshared --enable-registry
>> --enable-debug"
>> I build the test program with:
>> g++ queue-2.cpp -o queue-2 -g -fno-default-inline -fno-omit-frame-pointer
>> `xeno-config --skin=alchemy --cflags --no-auto-init --ldflags`
>> Changing the realloc_count parameter causes the code to fail at different
>> iterations; passing realloc_count = 3 moves the failure to the
>> rt_queue_send() call. (The code runs to completion with realloc_count set
>> to 1 or 2.)
>> I've also found that if I don't call rt_queue_free() the code runs to
>> completion.
>> Let me know if there's anything I can do to help.
> Your test code perfectly reproduces the issue here, thanks. There is a
> severe bitmap breakage, I'm on it.

Ugly bug affecting the page bitmap of the shared heap (--enable-pshared)
which caused the allocator to be terminally confused by some allocation
patterns. Fixed in the stable branch:




More information about the Xenomai mailing list