Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

Perrine Martignoni wrote:
 > On 5/9/07, Perrine Martignoni <perrmart@domain.hid> wrote:
 > >  On 5/9/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
 > > >
 > > > Noren, Andrew wrote:
 > > > > Hi Gilles,
 > > > >
 > > > > I too have encountered this issue with the POSIX skin.
 > > > > I think it may have to do with the order in which the posix skin hooks
 > > > > are run on thread deletion.
 > > > >
 > > > > In ksrc/skins/posix/syscall.c
 > > > > xnpod_remove_hook(XNHOOK_THREAD_DELETE, &__shadow_delete_hook);
 > > > >
 > > > > and ksrc/skins/posix/thread.c
 > > > > xnpod_add_hook(XNHOOK_THREAD_DELETE, thread_delete_hook);
 > > > >
 > > > > The thread_delete_hook seems to run first causing the thread data to
 > > > be
 > > > > destroyed before __shadow_delete_hook has a chance to run.
 > > > >
 > > > > This results in __shadow_delete_hook failing in various cases.
 > > > >
 > > > > An example of an error case linked with this would be the failure to
 > > > > remove the thread key from the hash bucket after application
 > > > exit.  The
 > > > > next run of an application can then result in pthread_setschedparam
 > > > > failing to create a shadow since it likely finds an id in the hash
 > > > > bucket already.
 > > >
 > > > Hi,
 > > >
 > > > thanks for pointing this out, I see other skins use xnfreesafe in their
 > > > thread deletion hook instead of xnfree. The attached patch fixes this.
 > > >
 > > > Perrine, could you apply this patch and check that it solves your issue
 > > > ?
 > >
 > > I'll do that as soon as I can.
 > > Thanks
 > >
 >
 > I have applied the patch.
 > It doesn't solve the problem but I have more information :
 > 
 > 
 > pthread_create returned 11
 > 
 > __pthread_shadow: -11
 > 
 > Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
 > unavailable

Ok, I could reproduce the problem. The issue is most likely an access to
the thread memory after it has been freed which breaks the allocator
linked list of free pages by replacing a link to a next free page by a
NULL pointer. xnheap_alloc interprets this NULL pointer as the end of the
linked list and hence considers that it is out of memory.

-- 


					    Gilles Chanteperdrix.