From: Benjamin ROUZAUD <brouzaud@numalliance.com>
To: xenomai@xenomai.org
Subject: Re: [Xenomai] Fwd: rt,Heap segfault with unittest
Date: Tue, 20 Dec 2016 11:07:36 +0100 [thread overview]
Message-ID: <585902E8.2050904@numalliance.com> (raw)
In-Reply-To: <585798F8.1060309@numalliance.com>
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.
>
next parent reply other threads:[~2016-12-20 10:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <585798F8.1060309@numalliance.com>
2016-12-20 10:07 ` Benjamin ROUZAUD [this message]
[not found] <583D46A3.7010206@numalliance.com>
2016-12-01 15:21 ` [Xenomai] Fwd: rt,Heap segfault with unittest Benjamin ROUZAUD
2016-12-03 17:16 ` Philippe Gerum
2016-12-27 15:20 ` Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=585902E8.2050904@numalliance.com \
--to=brouzaud@numalliance.com \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.