From mboxrd@z Thu Jan 1 00:00:00 1970 References: <55C22EED.4040704@xenomai.org> <55C326C5.4070608@xenomai.org> <55C37BF3.2070609@xenomai.org> From: Philippe Gerum Message-ID: <55C8BCDD.5000501@xenomai.org> Date: Mon, 10 Aug 2015 17:01:49 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] Segfaults and ENOMEM during rt_event_create() List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Charles Kiorpes Cc: xenomai@xenomai.org On 08/10/2015 03:52 PM, Charles Kiorpes wrote: >> This may be a memory corruption issue, some metadata from the shared >> heap got trashed earlier in the init sequence. >> >> Would it be practical to switch this app to the mercury core (no need >> for preempt-rt, just a plain regular desktop kernel), only for the >> purpose of running the init phase over valgrind? That would entail >> stubbing/bypassing the hardware-related inits (e.g. drivers) if ever >> possible. > > I reconfigured to use Mercury, but I can't reproduce the error in this > configuration. There is no longer any segfault, or ENOMEM. > > Despite being unable to reproduce the problem, Valgrind output > indicates something funny happening when I call rt_event_create() on > an object that already exists. > > Here's the output from Valgrind of what occurs when I call > rt_event_create() in pshared mode with an event that already exists > (I've truncated some of the call stacks, this is all from one call to > rt_event_create through a wrapper layer): > [snip] > This can be worked around by attempting an rt_event_bind() first and > only attempting to create the event if bind fails. > Is this case (trying to create an event flag with a conflicting name) part of the original scenario with Cobalt? > The above is the only complaint from Valgrind. > >> Also, does this bug happen with --disable-pshared? > > I am unable to run this application without pshared, because there are > two processes that need to signal each other using real-time events. Ok. -- Philippe.