[Xenomai-core] [bug] user memory leakage on rt_task_delete
Hi all, during my ongoing search for the init/cleanup issue of shadow threads, I stumbled over another problem: Deleting a userspace native thread that is blocked in primary mode does not let the NPTL clean up all resources allocated in userspace. If you plan to do some rt_task_create/delete in a loop, you will soon run out of memory (and Mr. oom-killer will show up...). I haven't found a solution for this beyond letting a rt-task always terminate itself (or terminate the whole program after forced deletions). If there is no solution, we should at least document this fact somewhere. Again, it's not a common use case, but it's also not an expectable behaviour of the native skin. Ok, back to work, Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [patch] fix rt_task_delete for cancellable rt-threads
Hi,
no, this is not the fix for the issue I described earlier. This just
improves the behaviour of rt_task_delete in case the target is blocking
at a cancellation point (tested with standard sem_wait). With the
current version, rt_task_deletes the rt-shadow and just wakes up the
linux pthread even if the target is cancellable at that moment. With the
reordering, this is fixed and the target is actually terminated. No
major issue, though.
Jan
Index: src/skins/native/task.c
===
--- src/skins/native/task.c (revision 243)
+++ src/skins/native/task.c (working copy)
@@ -203,12 +203,18 @@
int rt_task_delete (RT_TASK *task)
{
-int err = XENOMAI_SKINCALL1(__native_muxid,
- __native_task_delete,
- task);
-if (!err)
- pthread_cancel((pthread_t)task-opaque2);
+int err;
+err = pthread_cancel((pthread_t)task-opaque2)
+if (err)
+return -err;
+
+err = XENOMAI_SKINCALL1(__native_muxid,
+ __native_task_delete,
+ task);
+if (err == -ESRCH)
+ return 0;
+
return err;
}
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [doc-patch] rt_task_create user stack size
Hi, Please apply this, the statement is no longer valid. --- ksrc/skins/native/task.c(revision 243) +++ ksrc/skins/native/task.c(working copy) @@ -117,7 +117,7 @@ * * @param stksize The size of the stack (in bytes) for the new * task. If zero is passed, a reasonable pre-defined size will be - * substituted. This parameter is ignored for user-space tasks. + * substituted. * * @param prio The base priority of the new task. This value must * range from [1 .. 99] (inclusive) where 1 is the lowest effective Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] anonymous rt_tasks in userspace / registry dependencies
Hi again, some questions just came up for me: 1. Is it intended that tasks created with NULL name in userspace are not accessible even to the creator? I.e. don't they have to register anonymously in that case like semaphores e.g. do? 2. Doesn't render switching off XENO_OPT_NATIVE_REGISTRY the native skin unusable in userspace? If I got this correctly, all kernel objects are resolved from the user handle via the registry. If this is true, did I oversee some big fat warning sign somewhere...? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [patch] fix posix userspace headers
Good evening, this patch is required to compile some posix userspace program against 2.1 SVN. Jan Index: include/posix/signal.h === --- include/posix/signal.h (Revision 245) +++ include/posix/signal.h (Arbeitskopie) @@ -20,6 +20,12 @@ #ifndef _POSIX_SIGNAL_H #define _POSIX_SIGNAL_H +#ifndef __KERNEL__ + +#include_next signal.h + +#else /* __KERNEL__ */ + #include xenomai/posix/thread.h #define SIGACTION_FLAGS (SA_ONESHOT|SA_NOMASK|SA_SIGINFO) @@ -46,4 +52,6 @@ void pse51_signal_pkg_cleanup(void); +#endif /* !__KERNEL__ */ + #endif /* !_POSIX_SIGNAL_H */ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [bug?] set pthread stack size broken
Hi,
something for the night: Can someone explain why normal pthreads can be
restricted to initially use only the stack size provided via
pthread_attr_setstacksize() while any rt-mapped thread (posix and
native) refuse to accept this? For a simple test, compile the attached
program one time as normal
gcc -lpthread -o stacksize stacksize.c
and the other time against xeno's posix skin
gcc `xeno-config --posix-cflags` `xeno-config --posix-ldflags` \
-o stacksize.o stacksize.c
Then compare the memory requirements of both processes - they should
differ by 2M, the stack size when pthread_attr_setstacksize is not used.
Strange - and also critical when considering larger applications...
So far I only tested against 2.1, but I don't see a reason why 2.0.x
should behave different. Will get checked, though.
Any ideas?
Jan
#include sys/mman.h
#include unistd.h
#include limits.h
#include pthread.h
static void *simple_thread(void *arg)
{
sleep(30);
return 0;
}
int main (int ac, char **av)
{
pthread_t pth;
pthread_attr_t attr;
mlockall(MCL_CURRENT | MCL_FUTURE);
pthread_attr_init(attr);
pthread_attr_setstacksize(attr, PTHREAD_STACK_MIN);
pthread_create(pth, attr, simple_thread, NULL);
sleep(30);
return 0;
}
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [bug] user memory leakage on rt_task_delete
Hi all, during my ongoing search for the init/cleanup issue of shadow threads, I stumbled over another problem: Deleting a userspace native thread that is blocked in primary mode does not let the NPTL clean up all resources allocated in userspace. If you plan to do some rt_task_create/delete in a loop, you will soon run out of memory (and Mr. oom-killer will show up...). I haven't found a solution for this beyond letting a rt-task always terminate itself (or terminate the whole program after forced deletions). If there is no solution, we should at least document this fact somewhere. Again, it's not a common use case, but it's also not an expectable behaviour of the native skin. Ok, back to work, Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] [patch] fix rt_task_delete for cancellable rt-threads
Hi,
no, this is not the fix for the issue I described earlier. This just
improves the behaviour of rt_task_delete in case the target is blocking
at a cancellation point (tested with standard sem_wait). With the
current version, rt_task_deletes the rt-shadow and just wakes up the
linux pthread even if the target is cancellable at that moment. With the
reordering, this is fixed and the target is actually terminated. No
major issue, though.
Jan
Index: src/skins/native/task.c
===
--- src/skins/native/task.c (revision 243)
+++ src/skins/native/task.c (working copy)
@@ -203,12 +203,18 @@
int rt_task_delete (RT_TASK *task)
{
-int err = XENOMAI_SKINCALL1(__native_muxid,
- __native_task_delete,
- task);
-if (!err)
- pthread_cancel((pthread_t)task-opaque2);
+int err;
+err = pthread_cancel((pthread_t)task-opaque2)
+if (err)
+return -err;
+
+err = XENOMAI_SKINCALL1(__native_muxid,
+ __native_task_delete,
+ task);
+if (err == -ESRCH)
+ return 0;
+
return err;
}
signature.asc
Description: OpenPGP digital signature
[Xenomai-core] [doc-patch] rt_task_create user stack size
Hi, Please apply this, the statement is no longer valid. --- ksrc/skins/native/task.c(revision 243) +++ ksrc/skins/native/task.c(working copy) @@ -117,7 +117,7 @@ * * @param stksize The size of the stack (in bytes) for the new * task. If zero is passed, a reasonable pre-defined size will be - * substituted. This parameter is ignored for user-space tasks. + * substituted. * * @param prio The base priority of the new task. This value must * range from [1 .. 99] (inclusive) where 1 is the lowest effective Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] anonymous rt_tasks in userspace / registry dependencies
Hi again, some questions just came up for me: 1. Is it intended that tasks created with NULL name in userspace are not accessible even to the creator? I.e. don't they have to register anonymously in that case like semaphores e.g. do? 2. Doesn't render switching off XENO_OPT_NATIVE_REGISTRY the native skin unusable in userspace? If I got this correctly, all kernel objects are resolved from the user handle via the registry. If this is true, did I oversee some big fat warning sign somewhere...? Jan signature.asc Description: OpenPGP digital signature
[Xenomai-core] [patch] fix posix userspace headers
Good evening, this patch is required to compile some posix userspace program against 2.1 SVN. Jan Index: include/posix/signal.h === --- include/posix/signal.h (Revision 245) +++ include/posix/signal.h (Arbeitskopie) @@ -20,6 +20,12 @@ #ifndef _POSIX_SIGNAL_H #define _POSIX_SIGNAL_H +#ifndef __KERNEL__ + +#include_next signal.h + +#else /* __KERNEL__ */ + #include xenomai/posix/thread.h #define SIGACTION_FLAGS (SA_ONESHOT|SA_NOMASK|SA_SIGINFO) @@ -46,4 +52,6 @@ void pse51_signal_pkg_cleanup(void); +#endif /* !__KERNEL__ */ + #endif /* !_POSIX_SIGNAL_H */
