Gilles Chanteperdrix wrote:
> Perrine Martignoni wrote:
> > On 5/9/07, Perrine Martignoni <[EMAIL PROTECTED]> wrote:
> > > On 5/9/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> 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.
And the winner is... RPI! The offset of the thread structure member that
is set to NULL is the one of the rpi pointer. Disabling RPI makes the
problem vanish.
Philippe, when is this pointer set to NULL ?
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
