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:

http://git.xenomai.org/xenomai-3.git/commit/?h=stable-3.0.x&id=027898e4732cb5de9b2f1e762a61661ba9421d00

Thanks.

-- 
Philippe.

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Reply via email to