[Xenomai] Fwd: rt,Heap segfault with unittest

[Xenomai] Fwd: rt,Heap segfault with unittest

[Benjamin ROUZAUD]

Hello,

We made a new 32 bits system with xeno v3.0.3 .
first question, do we need to switch to git/next branch or keep it ?

During the execution of program using the library xenomai, we met a
problem about allocation memory between two process. Indeed, with a same
session, one program create the differents areas of memories but the
next try and fail. We create a unittest case that reproduces the bug between the
two process. But , since the problem has happened "randomly", depending on running context, we hope you will be able to
reproduce it.

Xenomai is configure with this flags :  --enable-smp, --enable-pshared
--enable-dlopen-libs --enable-tls

You will found the differents files at google drive (cf https://drive.google.com/drive/folders/0B7MmKH2j6iMYWjJfTzVOcFVTRDQ?usp=sharing).
  
You will find  modification of /alchemy/heap.c file trying to
search for the error at processing time. (cf enclosed heap.txt file)

You will find too the two tests programs with a makefile in enclosed heaptest.tar.gz file. The process B
create differents allocation areas and pauses.

projetB --session=t

the process C tries to create or link differents allocation areas but it crashes with segfault after many
creation.

projetC --session=t

Cordially,
B. Rouzaud
R&D Numalliance

Re: [Xenomai] Fwd: rt,Heap segfault with unittest

[Philippe Gerum]

On 12/01/2016 04:21 PM, Benjamin ROUZAUD wrote:

> the process C tries to create or link differents allocation areas but it
> crashes with segfault after many
> creation.
> 

Then you may want to run your test application over GDB, and inspect the
stack backtrace for locating the offending code. You could also build it
for Mercury in debug mode (--enable-debug=full) instead of Cobalt, and
use Valgrind to detect memory errors.

-- 
Philippe.

Re: [Xenomai] Fwd: rt,Heap segfault with unittest

[Philippe Gerum]

On 12/01/2016 04:21 PM, Benjamin ROUZAUD wrote:
> Hello,
> 
> We made a new 32 bits system with xeno v3.0.3 .
> first question, do we need to switch to git/next branch or keep it ?
> 

-next branch contains bleeding edge material scheduled for the next
major Xenomai release.

Since you are running the 3.0.x series, please check any issue against
the stable-3.0.x branch from the xenomai-3 repository first, before
reporting to the list if it did not go away.

http://xenomai.org/getting-the-xenomai-code/

-- 
Philippe.

Re: [Xenomai] Fwd: rt,Heap segfault with unittest

[Benjamin ROUZAUD]

Hello,

After your answer, we run our test application over GDB and inspect the
stack backtrace for locate the offending code.
We run the two applications with a session (run --session=mysession) and
the second return a seg fault with this backtrace :

#0  0xb7fa58bb in alloc_block () from /usr/xenomai/lib/libcopperplate.so.0
No symbol table info available.
#1  0xb7fb30f5 in rt_heap_create () from /usr/xenomai/lib/libalchemy.so.0
No symbol table info available.
#2  0x08049653 in mbuff_alloc (nom=nom@entry=0x804a7b0 "outil_automat",
taille=taille@entry=3353) at projetC.cpp:69
         ptr = 0xb6865578 ""
         err = <optimized out>
         already_allocated = 6144
         loc_taille = <optimized out>
#3  0x08049129 in main () at projetC.cpp:31

We try to debug and we find the line bug. This is the file

/lib/copperplate/heapobj-pshared.c

in the function

static void  *alloc_block(struct shared_heap *heap, size_t size)

at the line

heap->buckets[ilog].freelist = *((memoff_t *)block);

The bug appears when we try to allocate an existing block memory with
the function

rt_heap_create () from /usr/xenomai/lib/libalchemy.so.0

using xnmalloc()

We use a new 32 bits system with the xenomai-3.0.3 version (work with
the old xenomai-3. version). We find again the differents file at this
google drive (cf
https://drive.google.com/drive/folders/0B7MmKH2j6iMYWjJfTzVOcFVTRDQ?usp=sharing).

Cordially,
B. Rouzaud
R&D Numalliance




Le 03/12/2016 18:16, Philippe Gerum a écrit :
> On 12/01/2016 04:21 PM, Benjamin ROUZAUD wrote:
>
>> the process C tries to create or link differents allocation areas but it
>> crashes with segfault after many
>> creation.
>>
> Then you may want to run your test application over GDB, and inspect the
> stack backtrace for locating the offending code. You could also build it
> for Mercury in debug mode (--enable-debug=full) instead of Cobalt, and
> use Valgrind to detect memory errors.
>