[Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Thomas Wiedemann]

Hi,

there seems to be a bug in rt_task_create(). When no more memory is
available, the module usage counter of xeno_native is decremented. I
guess it is not incremented before, however, so the counter gets 0 and
wraps then to a negative number. It is therefore not possible to remove
the module.

I appended a small program to demonstrate this. It simply eats up all
memory from xenomai by registering as much mutexes as possible,
and then tries to execute rt_task_create(), which fails. When started
again, the bug occurs at rt_task_shadow(), as the mutexes have never
been deleted.
Compile with  gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config
 --xeno-ldflags` -lrtdm -lnative -o rttest rttest.c
then simply run it, and watch the output of lsmod before and after.

Tested with xenomai 2.2.{0,5} and linux 2.6.17.8, modules loaded:
xeno_native and xeno_nucleus.


Thomas Wiedemann


----
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <native/task.h>
#include <native/mutex.h>


static RT_TASK child, parent;

/* the entry point of the child process */
void childfn(void *cookie) {
        while(1) {
                rt_task_sleep(1000000000L);
                fprintf(stderr, "  hello, i'm the child.\n");
        }
}


int main(int argc, char *argv[]) {
        int num=0;

        mlockall(MCL_CURRENT|MCL_FUTURE);

        /* rt_task_shadow() can be ommitted, the bug still occurrs */
        if((num=rt_task_shadow(&parent,"rtserialtest",50,0))!=0) {
                fprintf(stderr,"Error creating rt task: %i ('%s')!\n", 
num, strerror(-num));
                exit(0);
        }

 
        fprintf(stderr, "Clobbering all mutexes... \n");
        while(1) {
                int i;
                RT_MUTEX m;
                if((i=rt_mutex_create(&m,NULL))<0) {
                        fprintf(stderr,"  -> After creating %i mutexes: 
Error <%i> ('%s')\n",num,i,strerror(-i));
                        break;
                }
                num++;
        }
 
        fprintf(stderr, "Creating child process ...\n");
        num=rt_task_create(&child, "rt_mutex_clobber_child", 0, 50, 0);
        if(num != 0) {
                fprintf(stderr, "  -> rt_task_create: failed: 
%s\n",strerror(-num));
        } else {
                fprintf(stderr, "  -> rt_task_create: OK! no bug.!\n");
        }
 
        return 0;
}

----

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Jan Kiszka]

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

Thomas Wiedemann wrote:
> Hi,
> 
> there seems to be a bug in rt_task_create(). When no more memory is
> available, the module usage counter of xeno_native is decremented. I
> guess it is not incremented before, however, so the counter gets 0 and
> wraps then to a negative number. It is therefore not possible to remove
> the module.
> 
> I appended a small program to demonstrate this. It simply eats up all
> memory from xenomai by registering as much mutexes as possible,
> and then tries to execute rt_task_create(), which fails. When started
> again, the bug occurs at rt_task_shadow(), as the mutexes have never
> been deleted.
> Compile with  gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config
>  --xeno-ldflags` -lrtdm -lnative -o rttest rttest.c
> then simply run it, and watch the output of lsmod before and after.
> 
> Tested with xenomai 2.2.{0,5} and linux 2.6.17.8, modules loaded:
> xeno_native and xeno_nucleus.
> 

Confirmed. Requires a closer look to find the leak path.

Thanks for reporting so thoroughly,
Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Thomas Wiedemann wrote:
> 
>>Hi,
>>
>>there seems to be a bug in rt_task_create(). When no more memory is
>>available, the module usage counter of xeno_native is decremented. I
>>guess it is not incremented before, however, so the counter gets 0 and
>>wraps then to a negative number. It is therefore not possible to remove
>>the module.
>>
>>I appended a small program to demonstrate this. It simply eats up all
>>memory from xenomai by registering as much mutexes as possible,
>>and then tries to execute rt_task_create(), which fails. When started
>>again, the bug occurs at rt_task_shadow(), as the mutexes have never
>>been deleted.
>>Compile with  gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config
>> --xeno-ldflags` -lrtdm -lnative -o rttest rttest.c
>>then simply run it, and watch the output of lsmod before and after.
>>
>>Tested with xenomai 2.2.{0,5} and linux 2.6.17.8, modules loaded:
>>xeno_native and xeno_nucleus.
>>
> 
> 
> Confirmed. Requires a closer look to find the leak path.

Here is what happens: the task is created with the XNSHADOW bit, and
destroyed before it was xnshadow_mapped, but the deletion hook calls
xnshadow_unmap because the task has the XNSHADOW bit. And xnshadow_unmap
 decrements the module count.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Gilles Chanteperdrix]

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> 
>>Thomas Wiedemann wrote:
>>
>>
>>>Hi,
>>>
>>>there seems to be a bug in rt_task_create(). When no more memory is
>>>available, the module usage counter of xeno_native is decremented. I
>>>guess it is not incremented before, however, so the counter gets 0 and
>>>wraps then to a negative number. It is therefore not possible to remove
>>>the module.
>>>
>>>I appended a small program to demonstrate this. It simply eats up all
>>>memory from xenomai by registering as much mutexes as possible,
>>>and then tries to execute rt_task_create(), which fails. When started
>>>again, the bug occurs at rt_task_shadow(), as the mutexes have never
>>>been deleted.
>>>Compile with  gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config
>>>--xeno-ldflags` -lrtdm -lnative -o rttest rttest.c
>>>then simply run it, and watch the output of lsmod before and after.
>>>
>>>Tested with xenomai 2.2.{0,5} and linux 2.6.17.8, modules loaded:
>>>xeno_native and xeno_nucleus.
>>>
>>
>>
>>Confirmed. Requires a closer look to find the leak path.
> 
> 
> Here is what happens: the task is created with the XNSHADOW bit, and
> destroyed before it was xnshadow_mapped, but the deletion hook calls
> xnshadow_unmap because the task has the XNSHADOW bit. And xnshadow_unmap
>  decrements the module count.

Here is an untested quick fix.

-- 
                                                 Gilles Chanteperdrix


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-avoid-unmapping-not-yet-mapped-shadow.diff --]
[-- Type: text/x-patch; name="xeno-avoid-unmapping-not-yet-mapped-shadow.diff", Size: 423 bytes --]

Index: ksrc/nucleus/shadow.c
===================================================================
--- ksrc/nucleus/shadow.c	(révision 1930)
+++ ksrc/nucleus/shadow.c	(copie de travail)
@@ -888,6 +888,9 @@
 
 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
 
+	if (!xnshadow_thrptd(p))
+		return;
+
 	magic = xnthread_get_magic(thread);
 
 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>
>>> Thomas Wiedemann wrote:
>>>
>>>
>>>> Hi,
>>>>
>>>> there seems to be a bug in rt_task_create(). When no more memory is
>>>> available, the module usage counter of xeno_native is decremented. I
>>>> guess it is not incremented before, however, so the counter gets 0 and
>>>> wraps then to a negative number. It is therefore not possible to remove
>>>> the module.
>>>>
>>>> I appended a small program to demonstrate this. It simply eats up all
>>>> memory from xenomai by registering as much mutexes as possible,
>>>> and then tries to execute rt_task_create(), which fails. When started
>>>> again, the bug occurs at rt_task_shadow(), as the mutexes have never
>>>> been deleted.
>>>> Compile with  gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config
>>>> --xeno-ldflags` -lrtdm -lnative -o rttest rttest.c
>>>> then simply run it, and watch the output of lsmod before and after.
>>>>
>>>> Tested with xenomai 2.2.{0,5} and linux 2.6.17.8, modules loaded:
>>>> xeno_native and xeno_nucleus.
>>>>
>>>
>>> Confirmed. Requires a closer look to find the leak path.
>>
>> Here is what happens: the task is created with the XNSHADOW bit, and
>> destroyed before it was xnshadow_mapped, but the deletion hook calls
>> xnshadow_unmap because the task has the XNSHADOW bit. And xnshadow_unmap
>>  decrements the module count.
> 
> Here is an untested quick fix.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: ksrc/nucleus/shadow.c
> ===================================================================
> --- ksrc/nucleus/shadow.c	(révision 1930)
> +++ ksrc/nucleus/shadow.c	(copie de travail)
> @@ -888,6 +888,9 @@
>  
>  	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
>  
> +	if (!xnshadow_thrptd(p))
> +		return;
> +
>  	magic = xnthread_get_magic(thread);
>  
>  	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {

Nope, shows unwanted side effects, probably because xnshadow_thrptd is
already NULL'ed in do_taskexit_event. Looks like it takes an extra flag, no?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Gilles Chanteperdrix]

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

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> 
>>Gilles Chanteperdrix wrote:
>>
>>>Jan Kiszka wrote:
>>>
>>>
>>>>Thomas Wiedemann wrote:
>>>>
>>>>
>>>>
>>>>>Hi,
>>>>>
>>>>>there seems to be a bug in rt_task_create(). When no more memory is
>>>>>available, the module usage counter of xeno_native is decremented. I
>>>>>guess it is not incremented before, however, so the counter gets 0 and
>>>>>wraps then to a negative number. It is therefore not possible to remove
>>>>>the module.
>>>>>
>>>>>I appended a small program to demonstrate this. It simply eats up all
>>>>>memory from xenomai by registering as much mutexes as possible,
>>>>>and then tries to execute rt_task_create(), which fails. When started
>>>>>again, the bug occurs at rt_task_shadow(), as the mutexes have never
>>>>>been deleted.
>>>>>Compile with  gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config
>>>>>--xeno-ldflags` -lrtdm -lnative -o rttest rttest.c
>>>>>then simply run it, and watch the output of lsmod before and after.
>>>>>
>>>>>Tested with xenomai 2.2.{0,5} and linux 2.6.17.8, modules loaded:
>>>>>xeno_native and xeno_nucleus.
>>>>>
>>>>
>>>>Confirmed. Requires a closer look to find the leak path.
>>>
>>>Here is what happens: the task is created with the XNSHADOW bit, and
>>>destroyed before it was xnshadow_mapped, but the deletion hook calls
>>>xnshadow_unmap because the task has the XNSHADOW bit. And xnshadow_unmap
>>> decrements the module count.
>>
>>Here is an untested quick fix.
>>
>>
>>
>>------------------------------------------------------------------------
>>
>>Index: ksrc/nucleus/shadow.c
>>===================================================================
>>--- ksrc/nucleus/shadow.c	(révision 1930)
>>+++ ksrc/nucleus/shadow.c	(copie de travail)
>>@@ -888,6 +888,9 @@
>> 
>> 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
>> 
>>+	if (!xnshadow_thrptd(p))
>>+		return;
>>+
>> 	magic = xnthread_get_magic(thread);
>> 
>> 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
> 
> 
> Nope, shows unwanted side effects, probably because xnshadow_thrptd is
> already NULL'ed in do_taskexit_event. Looks like it takes an extra flag, no?

Setting xnshadow_thrptd to NULL in do_taskexit_event does not seem to be
 that useful. Here comes version 2.

-- 
                                                 Gilles Chanteperdrix

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xeno-avoid-unmapping-not-yet-mapped-shadow.2.diff --]
[-- Type: text/x-patch; name="xeno-avoid-unmapping-not-yet-mapped-shadow.2.diff", Size: 728 bytes --]

Index: ksrc/nucleus/shadow.c
===================================================================
--- ksrc/nucleus/shadow.c	(révision 1930)
+++ ksrc/nucleus/shadow.c	(copie de travail)
@@ -888,6 +888,9 @@
 
 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
 
+	if (!xnshadow_thrptd(p))
+		return;
+
 	magic = xnthread_get_magic(thread);
 
 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
@@ -1639,8 +1642,6 @@
 		xnshadow_relax(0);
 
 	xnlock_get_irqsave(&nklock, s);
-	/* Prevent wakeup call from xnshadow_unmap(). */
-	xnshadow_thrptd(p) = NULL;
 	xnthread_archtcb(thread)->user_task = NULL;
 	/* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
 	xnpod_delete_thread(thread);

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>
>>> Gilles Chanteperdrix wrote:
>>>
>>>> Jan Kiszka wrote:
>>>>
>>>>
>>>>> Thomas Wiedemann wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> there seems to be a bug in rt_task_create(). When no more memory is
>>>>>> available, the module usage counter of xeno_native is decremented. I
>>>>>> guess it is not incremented before, however, so the counter gets 0 and
>>>>>> wraps then to a negative number. It is therefore not possible to remove
>>>>>> the module.
>>>>>>
>>>>>> I appended a small program to demonstrate this. It simply eats up all
>>>>>> memory from xenomai by registering as much mutexes as possible,
>>>>>> and then tries to execute rt_task_create(), which fails. When started
>>>>>> again, the bug occurs at rt_task_shadow(), as the mutexes have never
>>>>>> been deleted.
>>>>>> Compile with  gcc -O2 -Wall `xeno-config --xeno-cflags` `xeno-config
>>>>>> --xeno-ldflags` -lrtdm -lnative -o rttest rttest.c
>>>>>> then simply run it, and watch the output of lsmod before and after.
>>>>>>
>>>>>> Tested with xenomai 2.2.{0,5} and linux 2.6.17.8, modules loaded:
>>>>>> xeno_native and xeno_nucleus.
>>>>>>
>>>>> Confirmed. Requires a closer look to find the leak path.
>>>> Here is what happens: the task is created with the XNSHADOW bit, and
>>>> destroyed before it was xnshadow_mapped, but the deletion hook calls
>>>> xnshadow_unmap because the task has the XNSHADOW bit. And xnshadow_unmap
>>>> decrements the module count.
>>> Here is an untested quick fix.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Index: ksrc/nucleus/shadow.c
>>> ===================================================================
>>> --- ksrc/nucleus/shadow.c	(révision 1930)
>>> +++ ksrc/nucleus/shadow.c	(copie de travail)
>>> @@ -888,6 +888,9 @@
>>>
>>> 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
>>>
>>> +	if (!xnshadow_thrptd(p))
>>> +		return;
>>> +
>>> 	magic = xnthread_get_magic(thread);
>>>
>>> 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
>>
>> Nope, shows unwanted side effects, probably because xnshadow_thrptd is
>> already NULL'ed in do_taskexit_event. Looks like it takes an extra flag, no?
> 
> Setting xnshadow_thrptd to NULL in do_taskexit_event does not seem to be
>  that useful. Here comes version 2.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Index: ksrc/nucleus/shadow.c
> ===================================================================
> --- ksrc/nucleus/shadow.c	(révision 1930)
> +++ ksrc/nucleus/shadow.c	(copie de travail)
> @@ -888,6 +888,9 @@
>  
>  	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
>  
> +	if (!xnshadow_thrptd(p))
> +		return;
> +
>  	magic = xnthread_get_magic(thread);
>  
>  	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
> @@ -1639,8 +1642,6 @@
>  		xnshadow_relax(0);
>  
>  	xnlock_get_irqsave(&nklock, s);
> -	/* Prevent wakeup call from xnshadow_unmap(). */
> -	xnshadow_thrptd(p) = NULL;
>  	xnthread_archtcb(thread)->user_task = NULL;
>  	/* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
>  	xnpod_delete_thread(thread);

Can't comment on the correctness of the second hunk, but it
unfortunately doesn't change the situation that test case does not
longer terminate with the first hunk applied. May look like a trivial
issue - but it isn't. :->


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>>Index: ksrc/nucleus/shadow.c
>>===================================================================
>>--- ksrc/nucleus/shadow.c	(révision 1930)
>>+++ ksrc/nucleus/shadow.c	(copie de travail)
>>@@ -888,6 +888,9 @@
>> 
>> 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
>> 
>>+	if (!xnshadow_thrptd(p))
>>+		return;
>>+
>> 	magic = xnthread_get_magic(thread);
>> 
>> 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
>>@@ -1639,8 +1642,6 @@
>> 		xnshadow_relax(0);
>> 
>> 	xnlock_get_irqsave(&nklock, s);
>>-	/* Prevent wakeup call from xnshadow_unmap(). */
>>-	xnshadow_thrptd(p) = NULL;
>> 	xnthread_archtcb(thread)->user_task = NULL;
>> 	/* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
>> 	xnpod_delete_thread(thread);
> 
> 
> Can't comment on the correctness of the second hunk, but it
> unfortunately doesn't change the situation that test case does not
> longer terminate with the first hunk applied. May look like a trivial
> issue - but it isn't. :->
> 

Indeed. And xnshadow_thrptd(current) == NULL is used by xnpod_schedule,
so the patch is probably completely incorrect.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Philippe Gerum]

On Fri, 2006-12-08 at 19:02 +0100, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
> > Gilles Chanteperdrix wrote:
> >>Index: ksrc/nucleus/shadow.c
> >>===================================================================
> >>--- ksrc/nucleus/shadow.c	(révision 1930)
> >>+++ ksrc/nucleus/shadow.c	(copie de travail)
> >>@@ -888,6 +888,9 @@
> >> 
> >> 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
> >> 
> >>+	if (!xnshadow_thrptd(p))
> >>+		return;
> >>+
> >> 	magic = xnthread_get_magic(thread);
> >> 
> >> 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
> >>@@ -1639,8 +1642,6 @@
> >> 		xnshadow_relax(0);
> >> 
> >> 	xnlock_get_irqsave(&nklock, s);
> >>-	/* Prevent wakeup call from xnshadow_unmap(). */
> >>-	xnshadow_thrptd(p) = NULL;
> >> 	xnthread_archtcb(thread)->user_task = NULL;
> >> 	/* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
> >> 	xnpod_delete_thread(thread);
> > 
> > 
> > Can't comment on the correctness of the second hunk, but it
> > unfortunately doesn't change the situation that test case does not
> > longer terminate with the first hunk applied. May look like a trivial
> > issue - but it isn't. :->
> > 
> 
> Indeed. And xnshadow_thrptd(current) == NULL is used by xnpod_schedule,
> so the patch is probably completely incorrect.
> 

We should rather check the TCB backlink to the Linux task. Could someone
who can reproduce this issue, test the following patch? TIA,

--- ksrc/nucleus/shadow.c	(revision 1931)
+++ ksrc/nucleus/shadow.c	(working copy)
@@ -888,6 +888,10 @@
 
 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
 
+	xnltt_log_event(xeno_ev_shadowunmap, thread->name, p ? p->pid : -1);
+	if (!p)
+		goto renice_and_exit;
+
 	magic = xnthread_get_magic(thread);
 
 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
@@ -907,10 +911,6 @@
 		}
 	}
 
-	xnltt_log_event(xeno_ev_shadowunmap, thread->name, p ? p->pid : -1);
-	if (!p)
-		goto renice_and_exit;
-
 	xnshadow_thrptd(p) = NULL;
 
 	if (p->state != TASK_RUNNING) {

-- 
Philippe.

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Jan Kiszka]

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

Philippe Gerum wrote:
> On Fri, 2006-12-08 at 19:02 +0100, Gilles Chanteperdrix wrote:
>> Jan Kiszka wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Index: ksrc/nucleus/shadow.c
>>>> ===================================================================
>>>> --- ksrc/nucleus/shadow.c	(révision 1930)
>>>> +++ ksrc/nucleus/shadow.c	(copie de travail)
>>>> @@ -888,6 +888,9 @@
>>>>
>>>> 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
>>>>
>>>> +	if (!xnshadow_thrptd(p))
>>>> +		return;
>>>> +
>>>> 	magic = xnthread_get_magic(thread);
>>>>
>>>> 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
>>>> @@ -1639,8 +1642,6 @@
>>>> 		xnshadow_relax(0);
>>>>
>>>> 	xnlock_get_irqsave(&nklock, s);
>>>> -	/* Prevent wakeup call from xnshadow_unmap(). */
>>>> -	xnshadow_thrptd(p) = NULL;
>>>> 	xnthread_archtcb(thread)->user_task = NULL;
>>>> 	/* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
>>>> 	xnpod_delete_thread(thread);
>>>
>>> Can't comment on the correctness of the second hunk, but it
>>> unfortunately doesn't change the situation that test case does not
>>> longer terminate with the first hunk applied. May look like a trivial
>>> issue - but it isn't. :->
>>>
>> Indeed. And xnshadow_thrptd(current) == NULL is used by xnpod_schedule,
>> so the patch is probably completely incorrect.
>>
> 
> We should rather check the TCB backlink to the Linux task. Could someone
> who can reproduce this issue, test the following patch? TIA,
> 
> --- ksrc/nucleus/shadow.c	(revision 1931)
> +++ ksrc/nucleus/shadow.c	(working copy)
> @@ -888,6 +888,10 @@
>  
>  	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
>  
> +	xnltt_log_event(xeno_ev_shadowunmap, thread->name, p ? p->pid : -1);
> +	if (!p)
> +		goto renice_and_exit;
> +
>  	magic = xnthread_get_magic(thread);
>  
>  	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
> @@ -907,10 +911,6 @@
>  		}
>  	}
>  
> -	xnltt_log_event(xeno_ev_shadowunmap, thread->name, p ? p->pid : -1);
> -	if (!p)
> -		goto renice_and_exit;
> -
>  	xnshadow_thrptd(p) = NULL;
>  
>  	if (p->state != TASK_RUNNING) {
> 

Doesn't work, usage counter is now incremented. BTW, this patch slipped
into SVN with the iobitmap fix.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Philippe Gerum]

On Fri, 2006-12-08 at 20:05 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > On Fri, 2006-12-08 at 19:02 +0100, Gilles Chanteperdrix wrote:
> >> Jan Kiszka wrote:
> >>> Gilles Chanteperdrix wrote:
> >>>> Index: ksrc/nucleus/shadow.c
> >>>> ===================================================================
> >>>> --- ksrc/nucleus/shadow.c	(révision 1930)
> >>>> +++ ksrc/nucleus/shadow.c	(copie de travail)
> >>>> @@ -888,6 +888,9 @@
> >>>>
> >>>> 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
> >>>>
> >>>> +	if (!xnshadow_thrptd(p))
> >>>> +		return;
> >>>> +
> >>>> 	magic = xnthread_get_magic(thread);
> >>>>
> >>>> 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
> >>>> @@ -1639,8 +1642,6 @@
> >>>> 		xnshadow_relax(0);
> >>>>
> >>>> 	xnlock_get_irqsave(&nklock, s);
> >>>> -	/* Prevent wakeup call from xnshadow_unmap(). */
> >>>> -	xnshadow_thrptd(p) = NULL;
> >>>> 	xnthread_archtcb(thread)->user_task = NULL;
> >>>> 	/* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
> >>>> 	xnpod_delete_thread(thread);
> >>>
> >>> Can't comment on the correctness of the second hunk, but it
> >>> unfortunately doesn't change the situation that test case does not
> >>> longer terminate with the first hunk applied. May look like a trivial
> >>> issue - but it isn't. :->
> >>>
> >> Indeed. And xnshadow_thrptd(current) == NULL is used by xnpod_schedule,
> >> so the patch is probably completely incorrect.
> >>
> > 
> > We should rather check the TCB backlink to the Linux task. Could someone
> > who can reproduce this issue, test the following patch? TIA,
> > 
> > --- ksrc/nucleus/shadow.c	(revision 1931)
> > +++ ksrc/nucleus/shadow.c	(working copy)
> > @@ -888,6 +888,10 @@
> >  
> >  	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
> >  
> > +	xnltt_log_event(xeno_ev_shadowunmap, thread->name, p ? p->pid : -1);
> > +	if (!p)
> > +		goto renice_and_exit;
> > +
> >  	magic = xnthread_get_magic(thread);
> >  
> >  	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
> > @@ -907,10 +911,6 @@
> >  		}
> >  	}
> >  
> > -	xnltt_log_event(xeno_ev_shadowunmap, thread->name, p ? p->pid : -1);
> > -	if (!p)
> > -		goto renice_and_exit;
> > -
> >  	xnshadow_thrptd(p) = NULL;
> >  
> >  	if (p->state != TASK_RUNNING) {
> > 
> 
> Doesn't work, usage counter is now incremented. BTW, this patch slipped


Ok, I will try to reproduce it here before fixing.

> into SVN with the iobitmap fix.
> 

Should be reverted now.

-- 
Philippe.

Re: [Xenomai-core] [BUG] module usage counter of xenomai native corrupted (version 2.2.0 and 2.2.5)

[Philippe Gerum]

On Fri, 2006-12-08 at 22:35 +0100, Philippe Gerum wrote:
> On Fri, 2006-12-08 at 20:05 +0100, Jan Kiszka wrote:
> > Philippe Gerum wrote:
> > > On Fri, 2006-12-08 at 19:02 +0100, Gilles Chanteperdrix wrote:
> > >> Jan Kiszka wrote:
> > >>> Gilles Chanteperdrix wrote:
> > >>>> Index: ksrc/nucleus/shadow.c
> > >>>> ===================================================================
> > >>>> --- ksrc/nucleus/shadow.c	(révision 1930)
> > >>>> +++ ksrc/nucleus/shadow.c	(copie de travail)
> > >>>> @@ -888,6 +888,9 @@
> > >>>>
> > >>>> 	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
> > >>>>
> > >>>> +	if (!xnshadow_thrptd(p))
> > >>>> +		return;
> > >>>> +
> > >>>> 	magic = xnthread_get_magic(thread);
> > >>>>
> > >>>> 	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
> > >>>> @@ -1639,8 +1642,6 @@
> > >>>> 		xnshadow_relax(0);
> > >>>>
> > >>>> 	xnlock_get_irqsave(&nklock, s);
> > >>>> -	/* Prevent wakeup call from xnshadow_unmap(). */
> > >>>> -	xnshadow_thrptd(p) = NULL;
> > >>>> 	xnthread_archtcb(thread)->user_task = NULL;
> > >>>> 	/* xnpod_delete_thread() -> hook -> xnshadow_unmap(). */
> > >>>> 	xnpod_delete_thread(thread);
> > >>>
> > >>> Can't comment on the correctness of the second hunk, but it
> > >>> unfortunately doesn't change the situation that test case does not
> > >>> longer terminate with the first hunk applied. May look like a trivial
> > >>> issue - but it isn't. :->
> > >>>
> > >> Indeed. And xnshadow_thrptd(current) == NULL is used by xnpod_schedule,
> > >> so the patch is probably completely incorrect.
> > >>
> > > 
> > > We should rather check the TCB backlink to the Linux task. Could someone
> > > who can reproduce this issue, test the following patch? TIA,
> > > 
> > > --- ksrc/nucleus/shadow.c	(revision 1931)
> > > +++ ksrc/nucleus/shadow.c	(working copy)
> > > @@ -888,6 +888,10 @@
> > >  
> > >  	p = xnthread_archtcb(thread)->user_task;	/* May be != current */
> > >  
> > > +	xnltt_log_event(xeno_ev_shadowunmap, thread->name, p ? p->pid : -1);
> > > +	if (!p)
> > > +		goto renice_and_exit;
> > > +
> > >  	magic = xnthread_get_magic(thread);
> > >  
> > >  	for (muxid = 0; muxid < XENOMAI_MUX_NR; muxid++) {
> > > @@ -907,10 +911,6 @@
> > >  		}
> > >  	}
> > >  
> > > -	xnltt_log_event(xeno_ev_shadowunmap, thread->name, p ? p->pid : -1);
> > > -	if (!p)
> > > -		goto renice_and_exit;
> > > -
> > >  	xnshadow_thrptd(p) = NULL;
> > >  
> > >  	if (p->state != TASK_RUNNING) {
> > > 
> > 
> > Doesn't work, usage counter is now incremented. BTW, this patch slipped
> 
> 
> Ok, I will try to reproduce it here before fixing.
> 

Now fixed in both branches, v2.2.x and trunk.

-- 
Philippe.