Re: [Xenomai-help] Problem with pthread_setschedparam

Re: [Xenomai-help] Problem with pthread_setschedparam

[Noren, Andrew]

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.

Regards,
Andy

 

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 1203 bytes --]

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 ?

-- 
                                                 Gilles Chanteperdrix

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-posix-use-xnfreesafe.diff --]
[-- Type: text/x-patch; name="xeno-posix-use-xnfreesafe.diff", Size: 484 bytes --]

Index: ksrc/skins/posix/thread.c
===================================================================
--- ksrc/skins/posix/thread.c	(révision 2429)
+++ ksrc/skins/posix/thread.c	(copie de travail)
@@ -45,7 +45,7 @@
 	   called from pse51_thread_pkg_cleanup, hence the absence of
 	   xnpod_schedule(). */
 	xnsynch_destroy(&thread->join_synch);
-	xnfree(thread);
+	xnfreesafe(&thread->threadbase, thread, &thread->link);
 }
 
 static void thread_trampoline(void *cookie)

Re: [Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

I'll do that as soon as I can.
Thanks

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 ?
>
> --
>                                                 Gilles Chanteperdrix
>
>

[-- Attachment #2: Type: text/html, Size: 2040 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 1752 bytes --]

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


On 5/9/07, Perrine Martignoni <perrmart@domain.hid> wrote:
>
> I'll do that as soon as I can.
> Thanks
>
>  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
> > ?
> >
> > --
> >                                                 Gilles Chanteperdrix
> >
> >
>

[-- Attachment #2: Type: text/html, Size: 3035 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
 > 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.

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.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Philippe Gerum]

On Wed, 2007-05-09 at 23:23 +0200, Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>  > 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.
> 
> 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 ?
> 

When the thread leaves secondary mode or exits, which in turn removes it
from the queue the nucleus considers for priority boosting the root
thread. Check rpi_none().

-- 
Philippe.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 4254 bytes --]

Philippe Gerum wrote:
> On Wed, 2007-05-09 at 23:23 +0200, Gilles Chanteperdrix wrote:
> > Gilles Chanteperdrix wrote:
> >  > 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.
> > 
> > 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 ?
> > 
> 
> When the thread leaves secondary mode or exits, which in turn removes it
> from the queue the nucleus considers for priority boosting the root
> thread. Check rpi_none().

Conclusion: the problem is the one Andrew spotted, there are two
hooks and the shadow hook (which calls xnshadow_unmap, which in turn
calls rpi_pop, which sets the rpi pointer to null) gets called after the
other thread deletion hook which initially called xnfree, and now calls
xnfreesafe.

But it seems that even xnfreesafe is not safe enough, and it frees the
thread pointer immediately whereas we would like the operation to be
deferred.

This problem is a problem for all skins, the freed memory is accessed
after it has been freed, it is only visible with the posix
skin on ARM, because the offset of the rpi pointer is the same as the
place where the xnheap allocator stores the pointer to the next free
page.

So, I propose the following patch which makes xnfreesafe safer.

Other solutions are:
- call directly xnheap_schedule_free in thread deletion hooks
- change the execution order of the deletion hooks
- merge the two deletion hooks, enclosing the shadow deletion hook in an
 #ifdef CONFIG_XENO_OPT_PERVASIVE, to get sure of the execution order.

-- 
                                                 Gilles Chanteperdrix

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-safer-xnfreesafe.diff --]
[-- Type: text/x-patch; name="xeno-safer-xnfreesafe.diff", Size: 723 bytes --]

Index: include/nucleus/heap.h
===================================================================
--- include/nucleus/heap.h	(révision 3042)
+++ include/nucleus/heap.h	(copie de travail)
@@ -117,13 +117,7 @@
 #define xnmalloc(size)     xnheap_alloc(&kheap,size)
 #define xnfree(ptr)        xnheap_free(&kheap,ptr)
 #define xnfreesync()       xnheap_finalize_free(&kheap)
-#define xnfreesafe(thread,ptr,ln) \
-do { \
-    if (xnpod_current_thread() == thread) \
-	xnheap_schedule_free(&kheap,ptr,ln); \
-    else \
-	xnheap_free(&kheap,ptr); \
-} while(0)
+#define xnfreesafe(thread,ptr,ln) xnheap_schedule_free(&kheap,ptr,ln);
 
 static inline size_t xnheap_rounded_size (size_t hsize, size_t psize)
 {

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

Gilles Chanteperdrix wrote:
> +#define xnfreesafe(thread,ptr,ln) xnheap_schedule_free(&kheap,ptr,ln);

And without the semi-colon.

-- 
                                                 Gilles Chanteperdrix

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-safer-xnfreesafe.diff --]
[-- Type: text/x-patch; name="xeno-safer-xnfreesafe.diff", Size: 722 bytes --]

Index: include/nucleus/heap.h
===================================================================
--- include/nucleus/heap.h	(révision 3042)
+++ include/nucleus/heap.h	(copie de travail)
@@ -117,13 +117,7 @@
 #define xnmalloc(size)     xnheap_alloc(&kheap,size)
 #define xnfree(ptr)        xnheap_free(&kheap,ptr)
 #define xnfreesync()       xnheap_finalize_free(&kheap)
-#define xnfreesafe(thread,ptr,ln) \
-do { \
-    if (xnpod_current_thread() == thread) \
-	xnheap_schedule_free(&kheap,ptr,ln); \
-    else \
-	xnheap_free(&kheap,ptr); \
-} while(0)
+#define xnfreesafe(thread,ptr,ln) xnheap_schedule_free(&kheap,ptr,ln)
 
 static inline size_t xnheap_rounded_size (size_t hsize, size_t psize)
 {

Re: [Xenomai-help] Problem with pthread_setschedparam

[Daniel Schnell]

Hi,

Can this be related to the still unuanswered problem I was posting here:

https://mail.gna.org/public/xenomai-help/2007-05/msg00039.html

?

Best regards, 

-- 
Daniel Schnell                   | daniel.schnell@domain.hid
Hugbúnaðargerð                   | www.marel.com


-----Original Message-----
From: xenomai-help-bounces@domain.hid [mailto:xenomai-help-bounces@domain.hid] On Behalf Of Gilles Chanteperdrix
Sent: 10. maí 2007 08:34
To: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Problem with pthread_setschedparam

Philippe Gerum wrote:
> On Wed, 2007-05-09 at 23:23 +0200, Gilles Chanteperdrix wrote:
> > Gilles Chanteperdrix wrote:
> >  > 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.
> > 
> > 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 ?
> > 
> 
> When the thread leaves secondary mode or exits, which in turn removes 
> it from the queue the nucleus considers for priority boosting the root 
> thread. Check rpi_none().

Conclusion: the problem is the one Andrew spotted, there are two hooks and the shadow hook (which calls xnshadow_unmap, which in turn calls rpi_pop, which sets the rpi pointer to null) gets called after the other thread deletion hook which initially called xnfree, and now calls xnfreesafe.

But it seems that even xnfreesafe is not safe enough, and it frees the thread pointer immediately whereas we would like the operation to be deferred.

This problem is a problem for all skins, the freed memory is accessed after it has been freed, it is only visible with the posix skin on ARM, because the offset of the rpi pointer is the same as the place where the xnheap allocator stores the pointer to the next free page.

So, I propose the following patch which makes xnfreesafe safer.

Other solutions are:
- call directly xnheap_schedule_free in thread deletion hooks
- change the execution order of the deletion hooks
- merge the two deletion hooks, enclosing the shadow deletion hook in an  #ifdef CONFIG_XENO_OPT_PERVASIVE, to get sure of the execution order.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Daniel Schnell wrote:
> Hi,
> 
> Can this be related to the still unuanswered problem I was posting here:
> 
> https://mail.gna.org/public/xenomai-help/2007-05/msg00039.html
> 
> ?

The best way to know is to give a try to the patch (the second one).

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Daniel Schnell]

Hi,

Ran the patch. This did however not change the crash behaviour.

Wolfgang, as you have a Lite5200B and ELDK 3.1.1, could you confirm this (easy to reproduce) ?



Best regards,


Daniel Schnell.


-- 
Daniel Schnell                   | daniel.schnell@domain.hid
Hugbúnaðargerð                   | www.marel.com


-----Original Message-----
From: Gilles Chanteperdrix [mailto:gilles.chanteperdrix@xenomai.org
Sent: 10. maí 2007 09:12
To: Daniel Schnell
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Problem with pthread_setschedparam

Daniel Schnell wrote:
> Hi,
> 
> Can this be related to the still unuanswered problem I was posting here:
> 
> https://mail.gna.org/public/xenomai-help/2007-05/msg00039.html
> 
> ?

The best way to know is to give a try to the patch (the second one).

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Wolfgang Grandegger]

Hi Daniel,

Daniel Schnell wrote:
> Hi,
> 
> Ran the patch. This did however not change the crash behaviour.
> 
> Wolfgang, as you have a Lite5200B and ELDK 3.1.1, could you confirm this (easy to reproduce) ?

I did not fully follow the thread, what exactly do you want me to test 
on my Icecube-MPC5200.

Wolfgang.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Daniel Schnell]

Hi Wolfgang,

Here the link:

https://mail.gna.org/public/xenomai-help/2007-05/msg00039.html 


Just try the cyclictest program and end it with Ctrl-C. I would like to know if this works for you.

My configuration:
Linux 2.4.25, ELDK 3.1.1, Xenomai 2.3.1


Best regards,

-- 
Daniel Schnell                   | daniel.schnell@domain.hid
Hugbúnaðargerð                   | www.marel.com


-----Original Message-----
From: Wolfgang Grandegger [mailto:wg@domain.hid
Sent: 14. maí 2007 09:50
To: Daniel Schnell
Cc: Gilles Chanteperdrix; xenomai@xenomai.org
Subject: Re: [Xenomai-help] Problem with pthread_setschedparam

Hi Daniel,

Daniel Schnell wrote:
> Hi,
> 
> Ran the patch. This did however not change the crash behaviour.
> 
> Wolfgang, as you have a Lite5200B and ELDK 3.1.1, could you confirm this (easy to reproduce) ?

I did not fully follow the thread, what exactly do you want me to test on my Icecube-MPC5200.

Wolfgang.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Wolfgang Grandegger]

Daniel Schnell wrote:
> Hi Wolfgang,
> 
> Here the link:
> 
> https://mail.gna.org/public/xenomai-help/2007-05/msg00039.html 
> 
> 
> Just try the cyclictest program and end it with Ctrl-C. I would like to know if this works for you.
> 
> My configuration:
> Linux 2.4.25, ELDK 3.1.1, Xenomai 2.3.1

That works on my setup, Linux 2.4.25, ELDK 3.1.1 and Xenomai trunk, head 
of SVN.

Wolfgang.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Philippe Gerum]

On Thu, 2007-05-10 at 10:34 +0200, Gilles Chanteperdrix wrote:
> > >  > 
> > >  > 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 ?
> > > 
> > 
> > When the thread leaves secondary mode or exits, which in turn removes it
> > from the queue the nucleus considers for priority boosting the root
> > thread. Check rpi_none().
> 
> Conclusion: the problem is the one Andrew spotted, there are two
> hooks and the shadow hook (which calls xnshadow_unmap, which in turn
> calls rpi_pop, which sets the rpi pointer to null) gets called after the
> other thread deletion hook which initially called xnfree, and now calls
> xnfreesafe.
> 
> But it seems that even xnfreesafe is not safe enough, and it frees the
> thread pointer immediately whereas we would like the operation to be
> deferred.
> 

xnfreesafe was meant to prevent the caller from releasing some memory it
could still rely on, e.g. stack space, by postponing the actual release
until the idle thread is resumed. In your case, the problem is that it
does not account for the primary/secondary mode of a shadow thread.

> This problem is a problem for all skins, the freed memory is accessed
> after it has been freed, it is only visible with the posix
> skin on ARM, because the offset of the rpi pointer is the same as the
> place where the xnheap allocator stores the pointer to the next free
> page.
> 
> So, I propose the following patch which makes xnfreesafe safer.
> 
> Other solutions are:
> - call directly xnheap_schedule_free in thread deletion hooks

Yes, or make sure that xnfreesafe() behaves as expected. What about
this?

--- include/nucleus/heap.h	(revision 2427)
+++ include/nucleus/heap.h	(working copy)
@@ -118,7 +118,7 @@
 #define xnfreesync()       xnheap_finalize_free(&kheap)
 #define xnfreesafe(thread,ptr,ln) \
 do { \
-    if (xnpod_current_thread() == thread) \
+    if (xnpod_current_p(thread))	     \
 	xnheap_schedule_free(&kheap,ptr,ln); \
     else \
 	xnheap_free(&kheap,ptr); \
Index: include/nucleus/pod.h
===================================================================
--- include/nucleus/pod.h	(revision 2427)
+++ include/nucleus/pod.h	(working copy)
@@ -276,8 +276,16 @@
 #define xnpod_current_root() \
     (&xnpod_current_sched()->rootcb)
 
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+#define xnpod_current_p(thread)					\
+    ({ int __shadow_p = xnthread_test_state(thread, XNSHADOW);		\
+       int __curr_p = __shadow_p ? xnshadow_thread(current) == thread	\
+	   : thread == xnpod_current_thread();				\
+       __curr_p;})
+#else
 #define xnpod_current_p(thread) \
     (xnpod_current_thread() == (thread))
+#endif
 
 #define xnpod_locked_p() \
     (!!xnthread_test_state(xnpod_current_thread(),XNLOCK))

> - change the execution order of the deletion hooks
> - merge the two deletion hooks, enclosing the shadow deletion hook in an
>  #ifdef CONFIG_XENO_OPT_PERVASIVE, to get sure of the execution order.
> 

I'm reluctant to make this depend on some exact execution order of
asynchronous hooks. You never know what's going on in other parts of the
client code.

> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Thu, 2007-05-10 at 10:34 +0200, Gilles Chanteperdrix wrote:
> 
>>>> > 
>>>> > 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 ?
>>>>
>>>
>>>When the thread leaves secondary mode or exits, which in turn removes it
>>>from the queue the nucleus considers for priority boosting the root
>>>thread. Check rpi_none().
>>
>>Conclusion: the problem is the one Andrew spotted, there are two
>>hooks and the shadow hook (which calls xnshadow_unmap, which in turn
>>calls rpi_pop, which sets the rpi pointer to null) gets called after the
>>other thread deletion hook which initially called xnfree, and now calls
>>xnfreesafe.
>>
>>But it seems that even xnfreesafe is not safe enough, and it frees the
>>thread pointer immediately whereas we would like the operation to be
>>deferred.
>>
> 
> 
> xnfreesafe was meant to prevent the caller from releasing some memory it
> could still rely on, e.g. stack space, by postponing the actual release
> until the idle thread is resumed. In your case, the problem is that it
> does not account for the primary/secondary mode of a shadow thread.

I am not so sure. I mean, even if the thread was deleted from the
context of another thread, the two hooks would be invoked and we would
need the free operation to be deferred until after the execution of the
second hook.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 2377 bytes --]

It works fine when I disable RPI.
Thanks.

The patch xeno-safer-xnfreesafe allows to enable RPI?

On 5/10/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>
> Philippe Gerum wrote:
> > On Thu, 2007-05-10 at 10:34 +0200, Gilles Chanteperdrix wrote:
> >
> >>>> >
> >>>> > 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 ?
> >>>>
> >>>
> >>>When the thread leaves secondary mode or exits, which in turn removes
> it
> >>>from the queue the nucleus considers for priority boosting the root
> >>>thread. Check rpi_none().
> >>
> >>Conclusion: the problem is the one Andrew spotted, there are two
> >>hooks and the shadow hook (which calls xnshadow_unmap, which in turn
> >>calls rpi_pop, which sets the rpi pointer to null) gets called after the
> >>other thread deletion hook which initially called xnfree, and now calls
> >>xnfreesafe.
> >>
> >>But it seems that even xnfreesafe is not safe enough, and it frees the
> >>thread pointer immediately whereas we would like the operation to be
> >>deferred.
> >>
> >
> >
> > xnfreesafe was meant to prevent the caller from releasing some memory it
> > could still rely on, e.g. stack space, by postponing the actual release
> > until the idle thread is resumed. In your case, the problem is that it
> > does not account for the primary/secondary mode of a shadow thread.
>
> I am not so sure. I mean, even if the thread was deleted from the
> context of another thread, the two hooks would be invoked and we would
> need the free operation to be deferred until after the execution of the
> second hook.
>
> --
>                                                 Gilles Chanteperdrix
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>

[-- Attachment #2: Type: text/html, Size: 3394 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Perrine Martignoni wrote:
> It works fine when I disable RPI.
> Thanks.

It appears to be working, but the memory is accessed after it was freed,
so it may have other unwanted effects.

>  
> The patch xeno-safer-xnfreesafe allows to enable RPI?

Yes.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 710 bytes --]

I tried to apply the patch xeno-safer-xnfreesafe and enable RPI.
It doesn't work. I have the same problem :


pthread_create: failed to allocate TCB

pthread_create returned 11

__pthread_shadow: -11
Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
unavailable



On 5/10/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>
> Perrine Martignoni wrote:
> > It works fine when I disable RPI.
> > Thanks.
>
> It appears to be working, but the memory is accessed after it was freed,
> so it may have other unwanted effects.
>
> >
> > The patch xeno-safer-xnfreesafe allows to enable RPI?
>
> Yes.
>
> --
>                                                 Gilles Chanteperdrix
>

[-- Attachment #2: Type: text/html, Size: 1716 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Perrine Martignoni wrote:
> I tried to apply the patch xeno-safer-xnfreesafe and enable RPI.
> It doesn't work. I have the same problem :
>  
> 
> pthread_create: failed to allocate TCB
> 
> pthread_create returned 11
> 
> __pthread_shadow: -11
> 
> Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
> unavailable

That's because you also need to apply the patch which replaces xnfree
with xnfreesafe in thread_delete_hook.

The correct way to fix xnfreesafe is still on discussion. Please be
patient, we will release a cumulated patch when the issue is solved.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Philippe Gerum]

On Thu, 2007-05-10 at 11:33 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Thu, 2007-05-10 at 10:34 +0200, Gilles Chanteperdrix wrote:
> > 
> >>>> > 
> >>>> > 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 ?
> >>>>
> >>>
> >>>When the thread leaves secondary mode or exits, which in turn removes it
> >>>from the queue the nucleus considers for priority boosting the root
> >>>thread. Check rpi_none().
> >>
> >>Conclusion: the problem is the one Andrew spotted, there are two
> >>hooks and the shadow hook (which calls xnshadow_unmap, which in turn
> >>calls rpi_pop, which sets the rpi pointer to null) gets called after the
> >>other thread deletion hook which initially called xnfree, and now calls
> >>xnfreesafe.
> >>
> >>But it seems that even xnfreesafe is not safe enough, and it frees the
> >>thread pointer immediately whereas we would like the operation to be
> >>deferred.
> >>
> > 
> > 
> > xnfreesafe was meant to prevent the caller from releasing some memory it
> > could still rely on, e.g. stack space, by postponing the actual release
> > until the idle thread is resumed. In your case, the problem is that it
> > does not account for the primary/secondary mode of a shadow thread.
> 
> I am not so sure. I mean, even if the thread was deleted from the
> context of another thread, the two hooks would be invoked and we would
> need the free operation to be deferred until after the execution of the
> second hook.
> 

The point is that deletion hooks are always called on behalf of the
exiting thread in secondary mode, so if xnfreesafe properly identifies
the caller as the current thread - regardless of its exec mode - then
the deferral should always take place. But I agree on the fact that we
should always end up running the deferred call in this context anyway,
so we would be better off calling xnheap_schedule_free() directly.

-- 
Philippe.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> On Thu, 2007-05-10 at 11:33 +0200, Gilles Chanteperdrix wrote:
> 
>>Philippe Gerum wrote:
>>>xnfreesafe was meant to prevent the caller from releasing some memory it
>>>could still rely on, e.g. stack space, by postponing the actual release
>>>until the idle thread is resumed. In your case, the problem is that it
>>>does not account for the primary/secondary mode of a shadow thread.
>>
>>I am not so sure. I mean, even if the thread was deleted from the
>>context of another thread, the two hooks would be invoked and we would
>>need the free operation to be deferred until after the execution of the
>>second hook.
>>
> 
> 
> The point is that deletion hooks are always called on behalf of the
> exiting thread in secondary mode, so if xnfreesafe properly identifies
> the caller as the current thread - regardless of its exec mode - then
> the deferral should always take place. But I agree on the fact that we
> should always end up running the deferred call in this context anyway,
> so we would be better off calling xnheap_schedule_free() directly.

That is why, since xnfreesafe was only called in this precise context, I
redefined it to call xnheap_schedule_free directly.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Philippe Gerum]

On Thu, 2007-05-10 at 16:53 +0200, Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
> > On Thu, 2007-05-10 at 11:33 +0200, Gilles Chanteperdrix wrote:
> > 
> >>Philippe Gerum wrote:
> >>>xnfreesafe was meant to prevent the caller from releasing some memory it
> >>>could still rely on, e.g. stack space, by postponing the actual release
> >>>until the idle thread is resumed. In your case, the problem is that it
> >>>does not account for the primary/secondary mode of a shadow thread.
> >>
> >>I am not so sure. I mean, even if the thread was deleted from the
> >>context of another thread, the two hooks would be invoked and we would
> >>need the free operation to be deferred until after the execution of the
> >>second hook.
> >>
> > 
> > 
> > The point is that deletion hooks are always called on behalf of the
> > exiting thread in secondary mode, so if xnfreesafe properly identifies
> > the caller as the current thread - regardless of its exec mode - then
> > the deferral should always take place. But I agree on the fact that we
> > should always end up running the deferred call in this context anyway,
> > so we would be better off calling xnheap_schedule_free() directly.
> 
> That is why, since xnfreesafe was only called in this precise context, I
> redefined it to call xnheap_schedule_free directly.
> 

Well, ok. But we may need the xnfreesafe() interface in the future, the
way it was designed initially, I mean. So let's call
xnheap_schedule_free directly when needed.

-- 
Philippe.

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

Philippe Gerum wrote:
> On Thu, 2007-05-10 at 16:53 +0200, Gilles Chanteperdrix wrote:
> 
>>Philippe Gerum wrote:
>>
>>>On Thu, 2007-05-10 at 11:33 +0200, Gilles Chanteperdrix wrote:
>>>
>>>
>>>>Philippe Gerum wrote:
>>>>
>>>>>xnfreesafe was meant to prevent the caller from releasing some memory it
>>>>>could still rely on, e.g. stack space, by postponing the actual release
>>>>>until the idle thread is resumed. In your case, the problem is that it
>>>>>does not account for the primary/secondary mode of a shadow thread.
>>>>
>>>>I am not so sure. I mean, even if the thread was deleted from the
>>>>context of another thread, the two hooks would be invoked and we would
>>>>need the free operation to be deferred until after the execution of the
>>>>second hook.
>>>>
>>>
>>>
>>>The point is that deletion hooks are always called on behalf of the
>>>exiting thread in secondary mode, so if xnfreesafe properly identifies
>>>the caller as the current thread - regardless of its exec mode - then
>>>the deferral should always take place. But I agree on the fact that we
>>>should always end up running the deferred call in this context anyway,
>>>so we would be better off calling xnheap_schedule_free() directly.
>>
>>That is why, since xnfreesafe was only called in this precise context, I
>>redefined it to call xnheap_schedule_free directly.
>>
> 
> 
> Well, ok. But we may need the xnfreesafe() interface in the future, the
> way it was designed initially, I mean. So let's call
> xnheap_schedule_free directly when needed.
> 

Hence the final patch:

-- 
                                                 Gilles Chanteperdrix

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-use-xnheap_schedule_free.diff --]
[-- Type: text/x-patch; name="xeno-use-xnheap_schedule_free.diff", Size: 4116 bytes --]

Index: v2.3.x/include/nucleus/heap.h
===================================================================
--- v2.3.x/include/nucleus/heap.h	(révision 2429)
+++ v2.3.x/include/nucleus/heap.h	(copie de travail)
@@ -120,7 +120,7 @@
 #define xnfreesync()       xnheap_finalize_free(&kheap)
 #define xnfreesafe(thread,ptr,ln) \
 do { \
-    if (xnpod_current_thread() == thread) \
+    if (xnpod_current_p(thread))	     \
 	xnheap_schedule_free(&kheap,ptr,ln); \
     else \
 	xnheap_free(&kheap,ptr); \
Index: v2.3.x/include/nucleus/pod.h
===================================================================
--- v2.3.x/include/nucleus/pod.h	(révision 2429)
+++ v2.3.x/include/nucleus/pod.h	(copie de travail)
@@ -297,8 +297,16 @@
 #define xnpod_current_root() \
     (&xnpod_current_sched()->rootcb)
 
+#ifdef CONFIG_XENO_OPT_PERVASIVE
+#define xnpod_current_p(thread)					\
+    ({ int __shadow_p = xnthread_test_state(thread, XNSHADOW);		\
+       int __curr_p = __shadow_p ? xnshadow_thread(current) == thread	\
+	   : thread == xnpod_current_thread();				\
+       __curr_p;})
+#else
 #define xnpod_current_p(thread) \
     (xnpod_current_thread() == (thread))
+#endif
 
 #define xnpod_locked_p() \
     (!!xnthread_test_state(xnpod_current_thread(),XNLOCK))
Index: v2.3.x/ksrc/skins/psos+/task.c
===================================================================
--- v2.3.x/ksrc/skins/psos+/task.c	(révision 2429)
+++ v2.3.x/ksrc/skins/psos+/task.c	(copie de travail)
@@ -52,7 +52,7 @@
 	xnarch_delete_display(&task->threadbase);
 	psos_mark_deleted(task);
 
-	xnfreesafe(&task->threadbase, task, &task->link);
+	xnheap_schedule_free(&kheap, task, &task->link);
 }
 
 void psostask_init(u_long rrperiod)
Index: v2.3.x/ksrc/skins/rtai/task.c
===================================================================
--- v2.3.x/ksrc/skins/rtai/task.c	(révision 2429)
+++ v2.3.x/ksrc/skins/rtai/task.c	(copie de travail)
@@ -40,7 +40,7 @@
 	rtai_mark_deleted(task);
 
 	if (xnthread_test_state(&task->thread_base, XNSHADOW))
-		xnfreesafe(&task->thread_base, task, &task->link);
+		xnheap_schedule_free(&kheap, task, &task->link);
 }
 
 static void __task_switch_hook(xnthread_t *thread)
Index: v2.3.x/ksrc/skins/posix/thread.c
===================================================================
--- v2.3.x/ksrc/skins/posix/thread.c	(révision 2429)
+++ v2.3.x/ksrc/skins/posix/thread.c	(copie de travail)
@@ -45,7 +45,7 @@
 	   called from pse51_thread_pkg_cleanup, hence the absence of
 	   xnpod_schedule(). */
 	xnsynch_destroy(&thread->join_synch);
-	xnfree(thread);
+	xnheap_schedule_free(&kheap, thread, &thread->link);
 }
 
 static void thread_trampoline(void *cookie)
Index: v2.3.x/ksrc/skins/vrtx/task.c
===================================================================
--- v2.3.x/ksrc/skins/vrtx/task.c	(révision 2429)
+++ v2.3.x/ksrc/skins/vrtx/task.c	(copie de travail)
@@ -46,7 +46,7 @@
 
 	vrtx_mark_deleted(task);
 
-	xnfreesafe(&task->threadbase, task, &task->link);
+	xnheap_schedule_free(&kheap, task, &task->link);
 }
 
 int vrtxtask_init(u_long stacksize)
Index: v2.3.x/ksrc/skins/vxworks/taskLib.c
===================================================================
--- v2.3.x/ksrc/skins/vxworks/taskLib.c	(révision 2429)
+++ v2.3.x/ksrc/skins/vxworks/taskLib.c	(copie de travail)
@@ -605,7 +605,7 @@
 	wind_mark_deleted(task);
 
 	if (task->auto_delete)
-		xnfreesafe(&task->threadbase, task, &task->link);
+		xnheap_schedule_free(&kheap, task, &task->link);
 }
 
 static void wind_task_trampoline(void *cookie)
Index: v2.3.x/ksrc/skins/native/task.c
===================================================================
--- v2.3.x/ksrc/skins/native/task.c	(révision 2429)
+++ v2.3.x/ksrc/skins/native/task.c	(copie de travail)
@@ -76,7 +76,7 @@
 	xeno_mark_deleted(task);
 
 	if (xnthread_test_state(&task->thread_base, XNSHADOW))
-		xnfreesafe(&task->thread_base, task, &task->link);
+		xnheap_schedule_free(&kheap, task, &task->link);
 }
 
 void __native_task_safe(RT_TASK *task)

Re: [Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

I tested the final patch and it doesn't work on the file heap.h.
It seems I haven't the same code in the file at start. I use xenomai-2.3.1.
For which version is the patch?
Thanks

On 5/10/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>
> Philippe Gerum wrote:
> > On Thu, 2007-05-10 at 16:53 +0200, Gilles Chanteperdrix wrote:
> >
> >>Philippe Gerum wrote:
> >>
> >>>On Thu, 2007-05-10 at 11:33 +0200, Gilles Chanteperdrix wrote:
> >>>
> >>>
> >>>>Philippe Gerum wrote:
> >>>>
> >>>>>xnfreesafe was meant to prevent the caller from releasing some memory
> it
> >>>>>could still rely on, e.g. stack space, by postponing the actual
> release
> >>>>>until the idle thread is resumed. In your case, the problem is that
> it
> >>>>>does not account for the primary/secondary mode of a shadow thread.
> >>>>
> >>>>I am not so sure. I mean, even if the thread was deleted from the
> >>>>context of another thread, the two hooks would be invoked and we would
> >>>>need the free operation to be deferred until after the execution of
> the
> >>>>second hook.
> >>>>
> >>>
> >>>
> >>>The point is that deletion hooks are always called on behalf of the
> >>>exiting thread in secondary mode, so if xnfreesafe properly identifies
> >>>the caller as the current thread - regardless of its exec mode - then
> >>>the deferral should always take place. But I agree on the fact that we
> >>>should always end up running the deferred call in this context anyway,
> >>>so we would be better off calling xnheap_schedule_free() directly.
> >>
> >>That is why, since xnfreesafe was only called in this precise context, I
> >>redefined it to call xnheap_schedule_free directly.
> >>
> >
> >
> > Well, ok. But we may need the xnfreesafe() interface in the future, the
> > way it was designed initially, I mean. So let's call
> > xnheap_schedule_free directly when needed.
> >
>
> Hence the final patch:
>
> --
>                                                 Gilles Chanteperdrix
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
>
>

[-- Attachment #2: Type: text/html, Size: 3183 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Perrine Martignoni wrote:
> I tested the final patch and it doesn't work on the file heap.h.
> It seems I haven't the same code in the file at start. I use xenomai-2.3.1.
> For which version is the patch?
> Thanks

The patch applies cleanly on v2.3.x branch. Are you sure you have not
kept the changes made by a previous patch I sent ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

I solved my issue. It's because I kept a previous patch.

On 5/11/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>
> Perrine Martignoni wrote:
> > I tested the final patch and it doesn't work on the file heap.h.
> > It seems I haven't the same code in the file at start. I use
> xenomai-2.3.1.
> > For which version is the patch?
> > Thanks
>
> The patch applies cleanly on v2.3.x branch. Are you sure you have not
> kept the changes made by a previous patch I sent ?
>
> --
>                                                 Gilles Chanteperdrix
>

[-- Attachment #2: Type: text/html, Size: 1116 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

Thanks a lot. It works fine with the final patch.

On 5/11/07, Perrine Martignoni <perrmart@domain.hid> wrote:
>
> I solved my issue. It's because I kept a previous patch.
>
> On 5/11/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> >
> > Perrine Martignoni wrote:
> > > I tested the final patch and it doesn't work on the file heap.h.
> > > It seems I haven't the same code in the file at start. I use
> > xenomai-2.3.1.
> > > For which version is the patch?
> > > Thanks
> >
> > The patch applies cleanly on v2.3.x branch. Are you sure you have not
> > kept the changes made by a previous patch I sent ?
> >
> > --
> >                                                 Gilles Chanteperdrix
> >
>
>

[-- Attachment #2: Type: text/html, Size: 1624 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Philippe Gerum]

On Thu, 2007-05-10 at 17:45 +0200, Gilles Chanteperdrix wrote:

> Hence the final patch:
> 

Merged, thanks.

-- 
Philippe.

[Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 343 bytes --]

Hello,

I've build a xenomai test application with Posix skin wich run on an ARM9.
The application works well one time, and when I want to launch again my
application, I have this error message :


Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
unavailable



I think something was bad cancelled but I don't see.

Thanks

[-- Attachment #2: Type: text/html, Size: 728 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Perrine Martignoni wrote:
> Hello,
>  
> I've build a xenomai test application with Posix skin wich run on an
> ARM9. The application works well one time, and when I want to launch
> again my application, I have this error message :
>  
> 
> Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
> unavailable
> 
>  
> 
> I think something was bad cancelled but I don't see.

This may be a bug in Xenomai. Do you get the same effect with cyclictest
or switchtest ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

Perrine Martignoni wrote:
> Hello,
>  
> I've build a xenomai test application with Posix skin wich run on an
> ARM9. The application works well one time, and when I want to launch
> again my application, I have this error message :
>  
> 
> Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
> unavailable
> 
>  
> 
> I think something was bad cancelled but I don't see.

Resource temporarily unavailable is EAGAIN, it means that there is not
enough memory to create the real-time thread. Could you send us the
contents of /proc/xenomai/heap before and after running your application  ?

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-help] Problem with pthread_setschedparam

[Perrine Martignoni]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

I have exactly the same problem with cyclictest.

And here is the context of /proc/xenomai/heap before :

size=130560:used=64:pagesz=512

and after :


size=130560:used=64:pagesz=512



It doesn't change.



On 5/9/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>
> Perrine Martignoni wrote:
> > Hello,
> >
> > I've build a xenomai test application with Posix skin wich run on an
> > ARM9. The application works well one time, and when I want to launch
> > again my application, I have this error message :
> >
> >
> > Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
> > unavailable
> >
> >
> >
> > I think something was bad cancelled but I don't see.
>
> Resource temporarily unavailable is EAGAIN, it means that there is not
> enough memory to create the real-time thread. Could you send us the
> contents of /proc/xenomai/heap before and after running your
> application  ?
>
> --
>                                                 Gilles Chanteperdrix
>

[-- Attachment #2: Type: text/html, Size: 3976 bytes --]

Re: [Xenomai-help] Problem with pthread_setschedparam

[Gilles Chanteperdrix]

[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]

Perrine Martignoni wrote:
> On 5/9/07, *Gilles Chanteperdrix* <gilles.chanteperdrix@xenomai.org
> <mailto:gilles.chanteperdrix@xenomai.org>> wrote:
> 
>     Perrine Martignoni wrote:
>     > Hello,
>     >
>     > I've build a xenomai test application with Posix skin wich run on an
>     > ARM9. The application works well one time, and when I want to launch
>     > again my application, I have this error message :
>     >
>     >
>     > Xenomai Posix skin init: pthread_setschedparam: Resource temporarily
>     > unavailable
>     >
>     >
>     >
>     > I think something was bad cancelled but I don't see.
> 
>     Resource temporarily unavailable is EAGAIN, it means that there is not
>     enough memory to create the real-time thread. Could you send us the
>     contents of /proc/xenomai/heap before and after running your
>     application  ?
> 
> I have exactly the same problem with cyclictest.
>  
> And here is the context of /proc/xenomai/heap before :
>  
> size=130560:used=64:pagesz=512
>  
> and after :
>  
> 
> size=130560:used=64:pagesz=512
> 
>  
> 
> It doesn't change.

Ok, I will check this at home, since the ARM I have at work behaves
differently.

If you have some spare time, could you apply the attached patch,
recompile the kernel, and run your application ? This patch prints in
the kernel console which step in pthread_setschedparam returns an error.

-- 
                                                 Gilles Chanteperdrix

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-syscall-print-error.diff --]
[-- Type: text/x-patch; name="xeno-syscall-print-error.diff", Size: 1063 bytes --]

Index: ksrc/skins/posix/syscall.c
===================================================================
--- ksrc/skins/posix/syscall.c	(révision 2429)
+++ ksrc/skins/posix/syscall.c	(copie de travail)
@@ -202,13 +202,19 @@
 
 	err = pthread_create(&k_tid, &attr, NULL, NULL);
 
-	if (err)
+	if (err) {
+		printk("pthread_create returned %d\n", err);
 		return ERR_PTR(-err);
+	}
 
 	err = xnshadow_map(&k_tid->threadbase, NULL);
+	if (err)
+		printk("xnshadow_map returned %d\n", err);
 
-	if (!err && !__pthread_hash(hkey, k_tid))
+	if (!err && !__pthread_hash(hkey, k_tid)) {
+		printk("pthread_hash returned NULL\n");
 		err = -EAGAIN;
+	}
 
 	if (err)
 		pse51_thread_abort(k_tid, NULL);
@@ -244,8 +250,10 @@
 		/* If the syscall applies to "current", and the latter is not
 		   a Xenomai thread already, then shadow it. */
 		k_tid = __pthread_shadow(curr, &hkey);
-		if (IS_ERR(k_tid))
+		if (IS_ERR(k_tid)) {
+			printk("__pthread_shadow: %d\n", PTR_ERR(k_tid));
 			return PTR_ERR(k_tid);
+		}
 
 		promoted = 1;
 	}