Re: [Xenomai] Segfaults and ENOMEM during rt_event_create()

[Philippe Gerum <rpm@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.