[Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

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

hi,

i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
try to create a task with stacksize 2048, this worked with 2.4.10.
Because my app is written in pascal i have reproduced the problem with the
xenomai trivial-periodic.c example:

-	rt_task_create(&demo_task, "trivial", 0, 99, 0);
+	rt_task_create(&demo_task, "trivial",16911, 99, 0);

Stacksize 0 -> default stack size : ok
Stacksize > 0 and <= 16911 : Segmentation fault
Stacksize >= 16912 : ok

Any hints ?

thank you
kisda


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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Gilles Chanteperdrix]

Stefan Kisdaroczi wrote:
> hi,
> 
> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
> try to create a task with stacksize 2048, this worked with 2.4.10.
> Because my app is written in pascal i have reproduced the problem with the
> xenomai trivial-periodic.c example:
> 
> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
> 
> Stacksize 0 -> default stack size : ok
> Stacksize > 0 and <= 16911 : Segmentation fault
> Stacksize >= 16912 : ok
> 
> Any hints ?

What does the task do? If it uses printf, printf needs a lot of room on
the stack.

-- 
					    Gilles.

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

[-- Attachment #1.1: Type: text/plain, Size: 775 bytes --]

Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
> Stefan Kisdaroczi wrote:
>> hi,
>>
>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>> try to create a task with stacksize 2048, this worked with 2.4.10.
>> Because my app is written in pascal i have reproduced the problem with the
>> xenomai trivial-periodic.c example:
>>
>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>
>> Stacksize 0 -> default stack size : ok
>> Stacksize > 0 and <= 16911 : Segmentation fault
>> Stacksize >= 16912 : ok
>>
>> Any hints ?
> 
> What does the task do?

Nothing :-)

I have attached a patch for the trivial-periodic.c example to reproduce the problem.

thx
kisda

[-- Attachment #1.2: trivial-stacksize.diff --]
[-- Type: text/plain, Size: 1126 bytes --]

--- trivial-periodic.old	2009-03-31 10:51:10.000000000 +0200
+++ trivial-periodic.c	2010-01-07 16:24:28.000000000 +0100
@@ -12,30 +12,6 @@ RT_TASK demo_task;
 
 void demo(void *arg)
 {
-	RTIME now, previous;
-
-	/*
-	 * Arguments: &task (NULL=self),
-	 *            start time,
-	 *            period (here: 1 s)
-	 */
-	rt_task_set_periodic(NULL, TM_NOW, 1000000000);
-	previous = rt_timer_read();
-
-	while (1) {
-		rt_task_wait_period(NULL);
-		now = rt_timer_read();
-
-		/*
-		 * NOTE: printf may have unexpected impact on the timing of
-		 *       your program. It is used here in the critical loop
-		 *       only for demonstration purposes.
-		 */
-		printf("Time since last turn: %ld.%06ld ms\n",
-		       (long)(now - previous) / 1000000,
-		       (long)(now - previous) % 1000000);
-		       previous = now;
-	}
 }
 
 void catch_signal(int sig)
@@ -57,7 +33,7 @@ int main(int argc, char* argv[])
 	 *            priority,
 	 *            mode (FPU, start suspended, ...)
 	 */
-	rt_task_create(&demo_task, "trivial", 0, 99, 0);
+	rt_task_create(&demo_task, "trivial",16911, 99, 0);
 
 	/*
 	 * Arguments: &task,

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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

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

Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
> Stefan Kisdaroczi wrote:
>> hi,
>>
>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>> try to create a task with stacksize 2048, this worked with 2.4.10.
>> Because my app is written in pascal i have reproduced the problem with the
>> xenomai trivial-periodic.c example:
>>
>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>
>> Stacksize 0 -> default stack size : ok
>> Stacksize > 0 and <= 16911 : Segmentation fault
>> Stacksize >= 16912 : ok
>>
>> Any hints ?
> 
> What does the task do? If it uses printf, printf needs a lot of room on
> the stack.
> 

To clarify:
It does not depend on the task body, the task is not even started.
The segfault happens when calling rt_task_create(), before rt_task_start()
is called.

kisda


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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Gilles Chanteperdrix]

Stefan Kisdaroczi wrote:
> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>> Stefan Kisdaroczi wrote:
>>> hi,
>>>
>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>> Because my app is written in pascal i have reproduced the problem with the
>>> xenomai trivial-periodic.c example:
>>>
>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>
>>> Stacksize 0 -> default stack size : ok
>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>> Stacksize >= 16912 : ok
>>>
>>> Any hints ?
>> What does the task do? If it uses printf, printf needs a lot of room on
>> the stack.
>>
> 
> To clarify:
> It does not depend on the task body, the task is not even started.
> The segfault happens when calling rt_task_create(), before rt_task_start()
> is called.

Actually, when calling rt_task_create, the thread is created, under the
hood, and waits to be started. So the segmentation fault is most
certainly due to a stack overflow in the newly created thread.

And I am afraid I know why it happens: the newly merged user-space
signals support requires roughly 16 * sizeof(struct siginfo) on stack.
But this amounts to two Kbytes here. Could you run the following program
on your target ?

#include <stdio.h>
#include <signal.h>

struct xnsig {
        unsigned nsigs;
        unsigned remaining;
        struct {
                unsigned muxid;
                struct siginfo si;
        } pending[16];
};

int main(void)
{
        printf("%u\n", sizeof(struct xnsig));
        return 0;
}

-- 
					    Gilles.

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

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

Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
> Stefan Kisdaroczi wrote:
>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>> Stefan Kisdaroczi wrote:
>>>> hi,
>>>>
>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>> Because my app is written in pascal i have reproduced the problem with the
>>>> xenomai trivial-periodic.c example:
>>>>
>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>
>>>> Stacksize 0 -> default stack size : ok
>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>> Stacksize >= 16912 : ok
>>>>
>>>> Any hints ?
>>> What does the task do? If it uses printf, printf needs a lot of room on
>>> the stack.
>>>
>>
>> To clarify:
>> It does not depend on the task body, the task is not even started.
>> The segfault happens when calling rt_task_create(), before rt_task_start()
>> is called.
> 
> Actually, when calling rt_task_create, the thread is created, under the
> hood, and waits to be started. So the segmentation fault is most
> certainly due to a stack overflow in the newly created thread.
> 
> And I am afraid I know why it happens: the newly merged user-space
> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
> But this amounts to two Kbytes here. Could you run the following program
> on your target ?
> 
> #include <stdio.h>
> #include <signal.h>
> 
> struct xnsig {
>         unsigned nsigs;
>         unsigned remaining;
>         struct {
>                 unsigned muxid;
>                 struct siginfo si;
>         } pending[16];
> };
> 
> int main(void)
> {
>         printf("%u\n", sizeof(struct xnsig));
>         return 0;
> }
> 

output=2120
my system: debian lenny, linux 2.6.32.2, xenomai 2.5.0

kisda


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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

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

Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
> Stefan Kisdaroczi wrote:
>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>> Stefan Kisdaroczi wrote:
>>>> hi,
>>>>
>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>> Because my app is written in pascal i have reproduced the problem with the
>>>> xenomai trivial-periodic.c example:
>>>>
>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>
>>>> Stacksize 0 -> default stack size : ok
>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>> Stacksize >= 16912 : ok
>>>>
>>>> Any hints ?
>>> What does the task do? If it uses printf, printf needs a lot of room on
>>> the stack.
>>>
>>
>> To clarify:
>> It does not depend on the task body, the task is not even started.
>> The segfault happens when calling rt_task_create(), before rt_task_start()
>> is called.
> 
> Actually, when calling rt_task_create, the thread is created, under the
> hood, and waits to be started. So the segmentation fault is most
> certainly due to a stack overflow in the newly created thread.
> 
> And I am afraid I know why it happens: the newly merged user-space
> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
> But this amounts to two Kbytes here. Could you run the following program
> on your target ?

salut gilles,

as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
the value is too small, i suggest to take the stacksize needed by xenomai
into account too. The attached patch is clearly wrong, but it solved the
problem for me.

kisda

[-- Attachment #1.2: stacksize.diff --]
[-- Type: text/plain, Size: 457 bytes --]

--- xenomai-2.5.0.orig/src/skins/native/task.c
+++ xenomai-2.5.0/src/skins/native/task.c
@@ -148,9 +148,9 @@
 
 	if (!stksize)
 		stksize = 32 * 1024;
-	if (stksize < PTHREAD_STACK_MIN)
-		stksize = PTHREAD_STACK_MIN;
-
+	if (stksize < (PTHREAD_STACK_MIN + sizeof(struct xnsig)))
+		stksize = PTHREAD_STACK_MIN + sizeof(struct xnsig);
+	
 	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
 	memset(&param, 0, sizeof(param));
 	if (prio > 0) {

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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Gilles Chanteperdrix]

Stefan Kisdaroczi wrote:
> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>> Stefan Kisdaroczi wrote:
>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>> Stefan Kisdaroczi wrote:
>>>>> hi,
>>>>>
>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>> xenomai trivial-periodic.c example:
>>>>>
>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>
>>>>> Stacksize 0 -> default stack size : ok
>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>> Stacksize >= 16912 : ok
>>>>>
>>>>> Any hints ?
>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>> the stack.
>>>>
>>> To clarify:
>>> It does not depend on the task body, the task is not even started.
>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>> is called.
>> Actually, when calling rt_task_create, the thread is created, under the
>> hood, and waits to be started. So the segmentation fault is most
>> certainly due to a stack overflow in the newly created thread.
>>
>> And I am afraid I know why it happens: the newly merged user-space
>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>> But this amounts to two Kbytes here. Could you run the following program
>> on your target ?
> 
> salut gilles,
> 
> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
> the value is too small, i suggest to take the stacksize needed by xenomai
> into account too. The attached patch is clearly wrong, but it solved the
> problem for me.

PTHREAD_STACK_MIN varies a lot depending on architectures and even
depending on the glibc versions. Which is why we took 32 Kb as the
default stack size. Since the default is enough even for struct xnsig,
if you are asking a smaller size, you may have good reasons to do so. We
should check that the size is at least sizeof(struct xnsig), but since
PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.

The point is that your system seems to require 16 Kb whereas
sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
else.

Could you run the segfaulting program inside gdb, and print the frames
infos ?

-- 
					    Gilles.

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

[-- Attachment #1.1: Type: text/plain, Size: 2617 bytes --]

Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
> Stefan Kisdaroczi wrote:
>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>> Stefan Kisdaroczi wrote:
>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>> Stefan Kisdaroczi wrote:
>>>>>> hi,
>>>>>>
>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>> xenomai trivial-periodic.c example:
>>>>>>
>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>
>>>>>> Stacksize 0 -> default stack size : ok
>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>> Stacksize >= 16912 : ok
>>>>>>
>>>>>> Any hints ?
>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>> the stack.
>>>>>
>>>> To clarify:
>>>> It does not depend on the task body, the task is not even started.
>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>> is called.
>>> Actually, when calling rt_task_create, the thread is created, under the
>>> hood, and waits to be started. So the segmentation fault is most
>>> certainly due to a stack overflow in the newly created thread.
>>>
>>> And I am afraid I know why it happens: the newly merged user-space
>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>> But this amounts to two Kbytes here. Could you run the following program
>>> on your target ?
>>
>> salut gilles,
>>
>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>> the value is too small, i suggest to take the stacksize needed by xenomai
>> into account too. The attached patch is clearly wrong, but it solved the
>> problem for me.
> 
> PTHREAD_STACK_MIN varies a lot depending on architectures and even
> depending on the glibc versions. Which is why we took 32 Kb as the
> default stack size. Since the default is enough even for struct xnsig,
> if you are asking a smaller size, you may have good reasons to do so. We
> should check that the size is at least sizeof(struct xnsig), but since
> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
> 
> The point is that your system seems to require 16 Kb whereas
> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
> else.
> 
> Could you run the segfaulting program inside gdb, and print the frames
> infos ?

gdb logfile attached

kisda

[-- Attachment #1.2: gdb.txt --]
[-- Type: text/plain, Size: 3943 bytes --]

Starting program: /home/ski/src/xenotest/trivial-periodic 
[Thread debugging using libthread_db enabled]
[New Thread 0xb75ba6c0 (LWP 21336)]
[New Thread 0xb75b9b90 (LWP 21339)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb75b9b90 (LWP 21339)]
0xb7753783 in ?? () from /lib/ld-linux.so.2
#0  0xb7753783 in ?? () from /lib/ld-linux.so.2
#1  0xb77592e0 in ?? () from /lib/ld-linux.so.2
#2  0xb771f7fd in xeno_sigwinch_handler () from /usr/lib/libnative.so.3
#3  0xb771f8a6 in xeno_sigshadow_handler () from /usr/lib/libnative.so.3
#4  <signal handler called>
#5  0xb771e1e0 in ?? () from /usr/lib/libnative.so.3
#6  0xb75b93b8 in ?? ()
#7  0xb7721208 in ?? () from /usr/lib/libnative.so.3
#8  0xb77213c0 in ?? () from /usr/lib/libnative.so.3
#9  0xb771f700 in ?? () from /usr/lib/libnative.so.3
#10 0x00000000 in ?? ()
Stack frame at 0xb75b7008:
 eip = 0xb7753783; saved eip 0xb77592e0
 called by frame at 0xb75b7020
 Arglist at 0xb75b6ffc, args: 
 Locals at 0xb75b6ffc, Previous frame's sp is 0xb75b7008
 Saved registers:
  ebp at 0xb75b7000, eip at 0xb75b7004
Stack frame at 0xb75b7020:
 eip = 0xb77592e0; saved eip 0xb771f7fd
 called by frame at 0xb75b78a0, caller of frame at 0xb75b7008
 Arglist at 0xb75b7004, args: 
 Locals at 0xb75b7004, Previous frame's sp is 0xb75b7020
 Saved registers:
  eip at 0xb75b701c
Stack frame at 0xb75b78a0:
 eip = 0xb771f7fd in xeno_sigwinch_handler; saved eip 0xb771f8a6
 called by frame at 0xb75b7950, caller of frame at 0xb75b7020
 Arglist at 0xb75b7898, args: 
 Locals at 0xb75b7898, Previous frame's sp is 0xb75b78a0
 Saved registers:
  ebp at 0xb75b7898, eip at 0xb75b789c
Stack frame at 0xb75b7950:
 eip = 0xb771f8a6 in xeno_sigshadow_handler; saved eip 0xb774540c
 called by frame at 0xb75b7a58, caller of frame at 0xb75b78a0
 Arglist at 0xb75b7948, args: 
 Locals at 0xb75b7948, Previous frame's sp is 0xb75b7950
 Saved registers:
  ebp at 0xb75b7948, eip at 0xb75b794c
Stack frame at 0xb75b7a58:
 eip = 0xb774540c in __kernel_rt_sigreturn; saved eip 0xb771e1e0
 called by frame at 0xb75b7a5c, caller of frame at 0xb75b7950
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0xb75b7a58
 Saved registers:
  eax at 0xb75b7a1c, ecx at 0xb75b7a18, edx at 0xb75b7a14, ebx at 0xb75b7a10,
  ebp at 0xb75b7a08, esi at 0xb75b7a04, edi at 0xb75b7a00, eip at 0xb75b7a28
Stack frame at 0xb75b7a5c:
 eip = 0xb771e1e0; saved eip 0xb75b93b8
 called by frame at 0xb75b7a60, caller of frame at 0xb75b7a58
 Arglist at 0xb75b7a54, args: 
 Locals at 0xb75b7a54, Previous frame's sp is 0xb75b7a5c
 Saved registers:
  eip at 0xb75b7a58
Stack frame at 0xb75b7a60:
 eip = 0xb75b93b8; saved eip 0xb7721208
 called by frame at 0xb75b7a64, caller of frame at 0xb75b7a5c
 Arglist at 0xb75b7a58, args: 
 Locals at 0xb75b7a58, Previous frame's sp is 0xb75b7a60
 Saved registers:
  eip at 0xb75b7a5c
Stack frame at 0xb75b7a64:
 eip = 0xb7721208; saved eip 0xb77213c0
 called by frame at 0xb75b7a68, caller of frame at 0xb75b7a60
 Arglist at 0xb75b7a5c, args: 
 Locals at 0xb75b7a5c, Previous frame's sp is 0xb75b7a64
 Saved registers:
  eip at 0xb75b7a60
Stack frame at 0xb75b7a68:
 eip = 0xb77213c0 in xeno_sigshadow_installed; saved eip 0xb771f700
 called by frame at 0xb75b7a6c, caller of frame at 0xb75b7a64
 Arglist at 0xb75b7a60, args: 
 Locals at 0xb75b7a60, Previous frame's sp is 0xb75b7a68
 Saved registers:
  eip at 0xb75b7a64
Stack frame at 0xb75b7a6c:
 eip = 0xb771f700 in xeno_sigshadow_install; saved eip 0x0
 called by frame at 0xb75b7a70, caller of frame at 0xb75b7a68
 Arglist at 0xb75b7a64, args: 
 Locals at 0xb75b7a64, Previous frame's sp is 0xb75b7a6c
 Saved registers:
  eip at 0xb75b7a68
Stack frame at 0xb75b7a70:
 eip = 0x0; saved eip 0x0
 caller of frame at 0xb75b7a6c
 Arglist at 0xb75b7a68, args: 
 Locals at 0xb75b7a68, Previous frame's sp is 0xb75b7a70
 Saved registers:
  eip at 0xb75b7a6c
The program is running.  Exit anyway? (y or n) 

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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Gilles Chanteperdrix]

Stefan Kisdaroczi wrote:
> Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
>> Stefan Kisdaroczi wrote:
>>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>>> Stefan Kisdaroczi wrote:
>>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>>> Stefan Kisdaroczi wrote:
>>>>>>> hi,
>>>>>>>
>>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>>> xenomai trivial-periodic.c example:
>>>>>>>
>>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>>
>>>>>>> Stacksize 0 -> default stack size : ok
>>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>>> Stacksize >= 16912 : ok
>>>>>>>
>>>>>>> Any hints ?
>>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>>> the stack.
>>>>>>
>>>>> To clarify:
>>>>> It does not depend on the task body, the task is not even started.
>>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>>> is called.
>>>> Actually, when calling rt_task_create, the thread is created, under the
>>>> hood, and waits to be started. So the segmentation fault is most
>>>> certainly due to a stack overflow in the newly created thread.
>>>>
>>>> And I am afraid I know why it happens: the newly merged user-space
>>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>>> But this amounts to two Kbytes here. Could you run the following program
>>>> on your target ?
>>> salut gilles,
>>>
>>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>>> the value is too small, i suggest to take the stacksize needed by xenomai
>>> into account too. The attached patch is clearly wrong, but it solved the
>>> problem for me.
>> PTHREAD_STACK_MIN varies a lot depending on architectures and even
>> depending on the glibc versions. Which is why we took 32 Kb as the
>> default stack size. Since the default is enough even for struct xnsig,
>> if you are asking a smaller size, you may have good reasons to do so. We
>> should check that the size is at least sizeof(struct xnsig), but since
>> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
>>
>> The point is that your system seems to require 16 Kb whereas
>> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
>> else.
>>
>> Could you run the segfaulting program inside gdb, and print the frames
>> infos ?
> 
> gdb logfile attached

Ok. Could you get the value of the "esp" register at the time of the
failure, as well as the contents of /proc/<pid>/smaps where <pid> is the
pid of the failing application ? You can run the cat /proc/<pid>/smaps
when the process is stopped in gdb.

-- 
					    Gilles.

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

[-- Attachment #1.1: Type: text/plain, Size: 3083 bytes --]

Am 08.01.2010 14:30, schrieb Gilles Chanteperdrix:
> Stefan Kisdaroczi wrote:
>> Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
>>> Stefan Kisdaroczi wrote:
>>>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>>>> Stefan Kisdaroczi wrote:
>>>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>> hi,
>>>>>>>>
>>>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>>>> xenomai trivial-periodic.c example:
>>>>>>>>
>>>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>>>
>>>>>>>> Stacksize 0 -> default stack size : ok
>>>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>>>> Stacksize >= 16912 : ok
>>>>>>>>
>>>>>>>> Any hints ?
>>>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>>>> the stack.
>>>>>>>
>>>>>> To clarify:
>>>>>> It does not depend on the task body, the task is not even started.
>>>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>>>> is called.
>>>>> Actually, when calling rt_task_create, the thread is created, under the
>>>>> hood, and waits to be started. So the segmentation fault is most
>>>>> certainly due to a stack overflow in the newly created thread.
>>>>>
>>>>> And I am afraid I know why it happens: the newly merged user-space
>>>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>>>> But this amounts to two Kbytes here. Could you run the following program
>>>>> on your target ?
>>>> salut gilles,
>>>>
>>>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>>>> the value is too small, i suggest to take the stacksize needed by xenomai
>>>> into account too. The attached patch is clearly wrong, but it solved the
>>>> problem for me.
>>> PTHREAD_STACK_MIN varies a lot depending on architectures and even
>>> depending on the glibc versions. Which is why we took 32 Kb as the
>>> default stack size. Since the default is enough even for struct xnsig,
>>> if you are asking a smaller size, you may have good reasons to do so. We
>>> should check that the size is at least sizeof(struct xnsig), but since
>>> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
>>>
>>> The point is that your system seems to require 16 Kb whereas
>>> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
>>> else.
>>>
>>> Could you run the segfaulting program inside gdb, and print the frames
>>> infos ?
>>
>> gdb logfile attached
> 
> Ok. Could you get the value of the "esp" register at the time of the
> failure, as well as the contents of /proc/<pid>/smaps where <pid> is the
> pid of the failing application ? You can run the cat /proc/<pid>/smaps
> when the process is stopped in gdb.

attached.

kisda


[-- Attachment #1.2: registers.txt --]
[-- Type: text/plain, Size: 1320 bytes --]

Starting program: /home/ski/src/xenotest/trivial-periodic 
[Thread debugging using libthread_db enabled]
[New Thread 0xb75806c0 (LWP 21383)]
[New Thread 0xb757fb90 (LWP 21386)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb757fb90 (LWP 21386)]
0xb7719783 in ?? () from /lib/ld-linux.so.2
#0  0xb7719783 in ?? () from /lib/ld-linux.so.2
#1  0xb771f2e0 in ?? () from /lib/ld-linux.so.2
#2  0xb76e57fd in xeno_sigwinch_handler () from /usr/lib/libnative.so.3
#3  0xb76e58a6 in xeno_sigshadow_handler () from /usr/lib/libnative.so.3
#4  <signal handler called>
#5  0xb76e41e0 in ?? () from /usr/lib/libnative.so.3
#6  0xb757f3b8 in ?? ()
#7  0xb76e7208 in ?? () from /usr/lib/libnative.so.3
#8  0xb76e73c0 in ?? () from /usr/lib/libnative.so.3
#9  0xb76e5700 in ?? () from /usr/lib/libnative.so.3
#10 0x00000000 in ?? ()
eax            0xb77012a8	-1217391960
ecx            0xb757d9dc	-1218979364
edx            0xd0	208
ebx            0xb76e7208	-1217498616
esp            0xb757d000	0xb757d000
ebp            0xb757d000	0xb757d000
esi            0x63	99
edi            0x1c	28
eip            0xb7719783	0xb7719783
eflags         0x10206	[ PF IF RF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51

[-- Attachment #1.3: smaps.txt --]
[-- Type: text/plain, Size: 7816 bytes --]

08048000-08049000 r-xp 00000000 08:01 1976845    /home/ski/src/xenotest/trivial-periodic
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         4 kB
Private_Dirty:         0 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
08049000-0804a000 rw-p 00000000 08:01 1976845    /home/ski/src/xenotest/trivial-periodic
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
09e52000-09e73000 rw-p 00000000 00:00 0          [heap]
Size:                132 kB
Rss:                 132 kB
Pss:                 132 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:       132 kB
Referenced:          132 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b757c000-b757d000 ---p 00000000 00:00 0 
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b757d000-b7581000 rw-p 00000000 00:00 0 
Size:                 16 kB
Rss:                  16 kB
Pss:                  16 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        16 kB
Referenced:           16 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7581000-b76d6000 r-xp 00000000 08:01 4810048    /lib/i686/cmov/libc-2.7.so
Size:               1364 kB
Rss:                1364 kB
Pss:                 419 kB
Shared_Clean:       1364 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:         1364 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b76d6000-b76d7000 r--p 00155000 08:01 4810048    /lib/i686/cmov/libc-2.7.so
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b76d7000-b76d9000 rw-p 00156000 08:01 4810048    /lib/i686/cmov/libc-2.7.so
Size:                  8 kB
Rss:                   8 kB
Pss:                   8 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         8 kB
Referenced:            8 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b76d9000-b76dc000 rw-p 00000000 00:00 0 
Size:                 12 kB
Rss:                  12 kB
Pss:                  12 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        12 kB
Referenced:           12 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b76dc000-b76e7000 r-xp 00000000 08:01 958534     /usr/lib/libnative.so.3.0.0
Size:                 44 kB
Rss:                  44 kB
Pss:                  44 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:        12 kB
Private_Dirty:        32 kB
Referenced:           44 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b76e7000-b76e8000 rw-p 0000a000 08:01 958534     /usr/lib/libnative.so.3.0.0
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b76e8000-b76fd000 r-xp 00000000 08:01 4810062    /lib/i686/cmov/libpthread-2.7.so
Size:                 84 kB
Rss:                  84 kB
Pss:                  27 kB
Shared_Clean:         80 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:           84 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b76fd000-b76ff000 rw-p 00014000 08:01 4810062    /lib/i686/cmov/libpthread-2.7.so
Size:                  8 kB
Rss:                   8 kB
Pss:                   8 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         8 kB
Referenced:            8 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b76ff000-b7702000 rw-p 00000000 00:00 0 
Size:                 12 kB
Rss:                  12 kB
Pss:                  12 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        12 kB
Referenced:           12 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7704000-b7707000 rw-s 00000000 00:0d 1551       /dev/rtheap
Size:                 12 kB
Rss:                  12 kB
Pss:                   6 kB
Shared_Clean:         12 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           12 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7707000-b770a000 rw-s 00000000 00:0d 1551       /dev/rtheap
Size:                 12 kB
Rss:                  12 kB
Pss:                  12 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:        12 kB
Private_Dirty:         0 kB
Referenced:           12 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b770a000-b770b000 rw-p 00000000 00:00 0 
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b770b000-b770c000 r-xp 00000000 00:00 0          [vdso]
Size:                  4 kB
Rss:                   4 kB
Pss:                   0 kB
Shared_Clean:          4 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b770c000-b7726000 r-xp 00000000 08:01 4800514    /lib/ld-2.7.so
Size:                104 kB
Rss:                 104 kB
Pss:                  11 kB
Shared_Clean:        100 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:          104 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7726000-b7728000 rw-p 0001a000 08:01 4800514    /lib/ld-2.7.so
Size:                  8 kB
Rss:                   8 kB
Pss:                   8 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         8 kB
Referenced:            8 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
bfd96000-bfdab000 rw-p 00000000 00:00 0          [stack]
Size:                 84 kB
Rss:                  84 kB
Pss:                  84 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        84 kB
Referenced:           84 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB

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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Gilles Chanteperdrix]

Stefan Kisdaroczi wrote:
> Am 08.01.2010 14:30, schrieb Gilles Chanteperdrix:
>> Stefan Kisdaroczi wrote:
>>> Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
>>>> Stefan Kisdaroczi wrote:
>>>>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>>>>> Stefan Kisdaroczi wrote:
>>>>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>>> hi,
>>>>>>>>>
>>>>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>>>>> xenomai trivial-periodic.c example:
>>>>>>>>>
>>>>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>>>>
>>>>>>>>> Stacksize 0 -> default stack size : ok
>>>>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>>>>> Stacksize >= 16912 : ok
>>>>>>>>>
>>>>>>>>> Any hints ?
>>>>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>>>>> the stack.
>>>>>>>>
>>>>>>> To clarify:
>>>>>>> It does not depend on the task body, the task is not even started.
>>>>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>>>>> is called.
>>>>>> Actually, when calling rt_task_create, the thread is created, under the
>>>>>> hood, and waits to be started. So the segmentation fault is most
>>>>>> certainly due to a stack overflow in the newly created thread.
>>>>>>
>>>>>> And I am afraid I know why it happens: the newly merged user-space
>>>>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>>>>> But this amounts to two Kbytes here. Could you run the following program
>>>>>> on your target ?
>>>>> salut gilles,
>>>>>
>>>>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>>>>> the value is too small, i suggest to take the stacksize needed by xenomai
>>>>> into account too. The attached patch is clearly wrong, but it solved the
>>>>> problem for me.
>>>> PTHREAD_STACK_MIN varies a lot depending on architectures and even
>>>> depending on the glibc versions. Which is why we took 32 Kb as the
>>>> default stack size. Since the default is enough even for struct xnsig,
>>>> if you are asking a smaller size, you may have good reasons to do so. We
>>>> should check that the size is at least sizeof(struct xnsig), but since
>>>> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
>>>>
>>>> The point is that your system seems to require 16 Kb whereas
>>>> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
>>>> else.
>>>>
>>>> Could you run the segfaulting program inside gdb, and print the frames
>>>> infos ?
>>> gdb logfile attached
>> Ok. Could you get the value of the "esp" register at the time of the
>> failure, as well as the contents of /proc/<pid>/smaps where <pid> is the
>> pid of the failing application ? You can run the cat /proc/<pid>/smaps
>> when the process is stopped in gdb.
> 
> attached.

The values seem to depend on the run, I am afraid you will have to do it
all again at once. Once thing can be told for sure from your posts: a
Linux signal frame is stacked over Xenomai stack frame.

-- 
					    Gilles.

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

[-- Attachment #1.1: Type: text/plain, Size: 3502 bytes --]

Am 08.01.2010 14:52, schrieb Gilles Chanteperdrix:
> Stefan Kisdaroczi wrote:
>> Am 08.01.2010 14:30, schrieb Gilles Chanteperdrix:
>>> Stefan Kisdaroczi wrote:
>>>> Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
>>>>> Stefan Kisdaroczi wrote:
>>>>>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>>>> hi,
>>>>>>>>>>
>>>>>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>>>>>> xenomai trivial-periodic.c example:
>>>>>>>>>>
>>>>>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>>>>>
>>>>>>>>>> Stacksize 0 -> default stack size : ok
>>>>>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>>>>>> Stacksize >= 16912 : ok
>>>>>>>>>>
>>>>>>>>>> Any hints ?
>>>>>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>>>>>> the stack.
>>>>>>>>>
>>>>>>>> To clarify:
>>>>>>>> It does not depend on the task body, the task is not even started.
>>>>>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>>>>>> is called.
>>>>>>> Actually, when calling rt_task_create, the thread is created, under the
>>>>>>> hood, and waits to be started. So the segmentation fault is most
>>>>>>> certainly due to a stack overflow in the newly created thread.
>>>>>>>
>>>>>>> And I am afraid I know why it happens: the newly merged user-space
>>>>>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>>>>>> But this amounts to two Kbytes here. Could you run the following program
>>>>>>> on your target ?
>>>>>> salut gilles,
>>>>>>
>>>>>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>>>>>> the value is too small, i suggest to take the stacksize needed by xenomai
>>>>>> into account too. The attached patch is clearly wrong, but it solved the
>>>>>> problem for me.
>>>>> PTHREAD_STACK_MIN varies a lot depending on architectures and even
>>>>> depending on the glibc versions. Which is why we took 32 Kb as the
>>>>> default stack size. Since the default is enough even for struct xnsig,
>>>>> if you are asking a smaller size, you may have good reasons to do so. We
>>>>> should check that the size is at least sizeof(struct xnsig), but since
>>>>> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
>>>>>
>>>>> The point is that your system seems to require 16 Kb whereas
>>>>> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
>>>>> else.
>>>>>
>>>>> Could you run the segfaulting program inside gdb, and print the frames
>>>>> infos ?
>>>> gdb logfile attached
>>> Ok. Could you get the value of the "esp" register at the time of the
>>> failure, as well as the contents of /proc/<pid>/smaps where <pid> is the
>>> pid of the failing application ? You can run the cat /proc/<pid>/smaps
>>> when the process is stopped in gdb.
>>
>> attached.
> 
> The values seem to depend on the run, I am afraid you will have to do it
> all again at once. Once thing can be told for sure from your posts: a
> Linux signal frame is stacked over Xenomai stack frame.
> 

attached

[-- Attachment #1.2: gdb-and-smaps.txt --]
[-- Type: text/plain, Size: 12232 bytes --]

Starting program: /home/ski/src/xenotest/trivial-periodic 
[Thread debugging using libthread_db enabled]
[New Thread 0xb75eb6c0 (LWP 21509)]
[New Thread 0xb75eab90 (LWP 21512)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb75eab90 (LWP 21512)]
0xb7784783 in ?? () from /lib/ld-linux.so.2
#0  0xb7784783 in ?? () from /lib/ld-linux.so.2
#1  0xb778a2e0 in ?? () from /lib/ld-linux.so.2
#2  0xb77507fd in xeno_sigwinch_handler () from /usr/lib/libnative.so.3
#3  0xb77508a6 in xeno_sigshadow_handler () from /usr/lib/libnative.so.3
#4  <signal handler called>
#5  0xb774f1e0 in ?? () from /usr/lib/libnative.so.3
#6  0xb75ea3b8 in ?? ()
#7  0xb7752208 in ?? () from /usr/lib/libnative.so.3
#8  0xb77523c0 in ?? () from /usr/lib/libnative.so.3
#9  0xb7750700 in ?? () from /usr/lib/libnative.so.3
#10 0x00000000 in ?? ()
eax            0xb776c2a8	-1216953688
ecx            0xb75e89dc	-1218541092
edx            0xd0	208
ebx            0xb7752208	-1217060344
esp            0xb75e8000	0xb75e8000
ebp            0xb75e8000	0xb75e8000
esi            0x63	99
edi            0x1c	28
eip            0xb7784783	0xb7784783
eflags         0x10206	[ PF IF RF ]
cs             0x73	115
ss             0x7b	123
ds             0x7b	123
es             0x7b	123
fs             0x0	0
gs             0x33	51
Stack frame at 0xb75e8008:
 eip = 0xb7784783; saved eip 0xb778a2e0
 called by frame at 0xb75e8020
 Arglist at 0xb75e7ffc, args: 
 Locals at 0xb75e7ffc, Previous frame's sp is 0xb75e8008
 Saved registers:
  ebp at 0xb75e8000, eip at 0xb75e8004
Stack frame at 0xb75e8020:
 eip = 0xb778a2e0; saved eip 0xb77507fd
 called by frame at 0xb75e88a0, caller of frame at 0xb75e8008
 Arglist at 0xb75e8004, args: 
 Locals at 0xb75e8004, Previous frame's sp is 0xb75e8020
 Saved registers:
  eip at 0xb75e801c
Stack frame at 0xb75e88a0:
 eip = 0xb77507fd in xeno_sigwinch_handler; saved eip 0xb77508a6
 called by frame at 0xb75e8950, caller of frame at 0xb75e8020
 Arglist at 0xb75e8898, args: 
 Locals at 0xb75e8898, Previous frame's sp is 0xb75e88a0
 Saved registers:
  ebp at 0xb75e8898, eip at 0xb75e889c
Stack frame at 0xb75e8950:
 eip = 0xb77508a6 in xeno_sigshadow_handler; saved eip 0xb777640c
 called by frame at 0xb75e8a58, caller of frame at 0xb75e88a0
 Arglist at 0xb75e8948, args: 
 Locals at 0xb75e8948, Previous frame's sp is 0xb75e8950
 Saved registers:
  ebp at 0xb75e8948, eip at 0xb75e894c
Stack frame at 0xb75e8a58:
 eip = 0xb777640c in __kernel_rt_sigreturn; saved eip 0xb774f1e0
 called by frame at 0xb75e8a5c, caller of frame at 0xb75e8950
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0xb75e8a58
 Saved registers:
  eax at 0xb75e8a1c, ecx at 0xb75e8a18, edx at 0xb75e8a14, ebx at 0xb75e8a10,
  ebp at 0xb75e8a08, esi at 0xb75e8a04, edi at 0xb75e8a00, eip at 0xb75e8a28
Stack frame at 0xb75e8a5c:
 eip = 0xb774f1e0; saved eip 0xb75ea3b8
 called by frame at 0xb75e8a60, caller of frame at 0xb75e8a58
 Arglist at 0xb75e8a54, args: 
 Locals at 0xb75e8a54, Previous frame's sp is 0xb75e8a5c
 Saved registers:
  eip at 0xb75e8a58
Stack frame at 0xb75e8a60:
 eip = 0xb75ea3b8; saved eip 0xb7752208
 called by frame at 0xb75e8a64, caller of frame at 0xb75e8a5c
 Arglist at 0xb75e8a58, args: 
 Locals at 0xb75e8a58, Previous frame's sp is 0xb75e8a60
 Saved registers:
  eip at 0xb75e8a5c
Stack frame at 0xb75e8a64:
 eip = 0xb7752208; saved eip 0xb77523c0
 called by frame at 0xb75e8a68, caller of frame at 0xb75e8a60
 Arglist at 0xb75e8a5c, args: 
 Locals at 0xb75e8a5c, Previous frame's sp is 0xb75e8a64
 Saved registers:
  eip at 0xb75e8a60
Stack frame at 0xb75e8a68:
 eip = 0xb77523c0 in xeno_sigshadow_installed; saved eip 0xb7750700
 called by frame at 0xb75e8a6c, caller of frame at 0xb75e8a64
 Arglist at 0xb75e8a60, args: 
 Locals at 0xb75e8a60, Previous frame's sp is 0xb75e8a68
 Saved registers:
  eip at 0xb75e8a64
Stack frame at 0xb75e8a6c:
 eip = 0xb7750700 in xeno_sigshadow_install; saved eip 0x0
 called by frame at 0xb75e8a70, caller of frame at 0xb75e8a68
 Arglist at 0xb75e8a64, args: 
 Locals at 0xb75e8a64, Previous frame's sp is 0xb75e8a6c
 Saved registers:
  eip at 0xb75e8a68
Stack frame at 0xb75e8a70:
 eip = 0x0; saved eip 0x0
 caller of frame at 0xb75e8a6c
 Arglist at 0xb75e8a68, args: 
 Locals at 0xb75e8a68, Previous frame's sp is 0xb75e8a70
 Saved registers:
  eip at 0xb75e8a6c
The program is running.  Exit anyway? (y or n)


08048000-08049000 r-xp 00000000 08:01 1976845    /home/ski/src/xenotest/trivial-periodic
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         4 kB
Private_Dirty:         0 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
08049000-0804a000 rw-p 00000000 08:01 1976845    /home/ski/src/xenotest/trivial-periodic
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
099eb000-09a0c000 rw-p 00000000 00:00 0          [heap]
Size:                132 kB
Rss:                 132 kB
Pss:                 132 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:       132 kB
Referenced:          132 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b75e7000-b75e8000 ---p 00000000 00:00 0 
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b75e8000-b75ec000 rw-p 00000000 00:00 0 
Size:                 16 kB
Rss:                  16 kB
Pss:                  16 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        16 kB
Referenced:           16 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b75ec000-b7741000 r-xp 00000000 08:01 4810048    /lib/i686/cmov/libc-2.7.so
Size:               1364 kB
Rss:                1364 kB
Pss:                 404 kB
Shared_Clean:       1364 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:         1364 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7741000-b7742000 r--p 00155000 08:01 4810048    /lib/i686/cmov/libc-2.7.so
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7742000-b7744000 rw-p 00156000 08:01 4810048    /lib/i686/cmov/libc-2.7.so
Size:                  8 kB
Rss:                   8 kB
Pss:                   8 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         8 kB
Referenced:            8 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7744000-b7747000 rw-p 00000000 00:00 0 
Size:                 12 kB
Rss:                  12 kB
Pss:                  12 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        12 kB
Referenced:           12 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7747000-b7752000 r-xp 00000000 08:01 958534     /usr/lib/libnative.so.3.0.0
Size:                 44 kB
Rss:                  44 kB
Pss:                  44 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:        12 kB
Private_Dirty:        32 kB
Referenced:           44 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7752000-b7753000 rw-p 0000a000 08:01 958534     /usr/lib/libnative.so.3.0.0
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7753000-b7768000 r-xp 00000000 08:01 4810062    /lib/i686/cmov/libpthread-2.7.so
Size:                 84 kB
Rss:                  84 kB
Pss:                  24 kB
Shared_Clean:         80 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:           84 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7768000-b776a000 rw-p 00014000 08:01 4810062    /lib/i686/cmov/libpthread-2.7.so
Size:                  8 kB
Rss:                   8 kB
Pss:                   8 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         8 kB
Referenced:            8 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b776a000-b776d000 rw-p 00000000 00:00 0 
Size:                 12 kB
Rss:                  12 kB
Pss:                  12 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        12 kB
Referenced:           12 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b776f000-b7772000 rw-s 00000000 00:0d 1551       /dev/rtheap
Size:                 12 kB
Rss:                  12 kB
Pss:                   6 kB
Shared_Clean:         12 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:           12 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7772000-b7775000 rw-s 00000000 00:0d 1551       /dev/rtheap
Size:                 12 kB
Rss:                  12 kB
Pss:                  12 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:        12 kB
Private_Dirty:         0 kB
Referenced:           12 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7775000-b7776000 rw-p 00000000 00:00 0 
Size:                  4 kB
Rss:                   4 kB
Pss:                   4 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7776000-b7777000 r-xp 00000000 00:00 0          [vdso]
Size:                  4 kB
Rss:                   4 kB
Pss:                   0 kB
Shared_Clean:          4 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         0 kB
Referenced:            4 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7777000-b7791000 r-xp 00000000 08:01 4800514    /lib/ld-2.7.so
Size:                104 kB
Rss:                 104 kB
Pss:                  10 kB
Shared_Clean:        100 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         4 kB
Referenced:          104 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
b7791000-b7793000 rw-p 0001a000 08:01 4800514    /lib/ld-2.7.so
Size:                  8 kB
Rss:                   8 kB
Pss:                   8 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:         8 kB
Referenced:            8 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB
bfd6a000-bfd7f000 rw-p 00000000 00:00 0          [stack]
Size:                 84 kB
Rss:                  84 kB
Pss:                  84 kB
Shared_Clean:          0 kB
Shared_Dirty:          0 kB
Private_Clean:         0 kB
Private_Dirty:        84 kB
Referenced:           84 kB
Swap:                  0 kB
KernelPageSize:        4 kB
MMUPageSize:           4 kB

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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Gilles Chanteperdrix]

Stefan Kisdaroczi wrote:
> Am 08.01.2010 14:30, schrieb Gilles Chanteperdrix:
>> Stefan Kisdaroczi wrote:
>>> Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
>>>> Stefan Kisdaroczi wrote:
>>>>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>>>>> Stefan Kisdaroczi wrote:
>>>>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>>> hi,
>>>>>>>>>
>>>>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>>>>> xenomai trivial-periodic.c example:
>>>>>>>>>
>>>>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>>>>
>>>>>>>>> Stacksize 0 -> default stack size : ok
>>>>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>>>>> Stacksize >= 16912 : ok
>>>>>>>>>
>>>>>>>>> Any hints ?
>>>>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>>>>> the stack.
>>>>>>>>
>>>>>>> To clarify:
>>>>>>> It does not depend on the task body, the task is not even started.
>>>>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>>>>> is called.
>>>>>> Actually, when calling rt_task_create, the thread is created, under the
>>>>>> hood, and waits to be started. So the segmentation fault is most
>>>>>> certainly due to a stack overflow in the newly created thread.
>>>>>>
>>>>>> And I am afraid I know why it happens: the newly merged user-space
>>>>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>>>>> But this amounts to two Kbytes here. Could you run the following program
>>>>>> on your target ?
>>>>> salut gilles,
>>>>>
>>>>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>>>>> the value is too small, i suggest to take the stacksize needed by xenomai
>>>>> into account too. The attached patch is clearly wrong, but it solved the
>>>>> problem for me.
>>>> PTHREAD_STACK_MIN varies a lot depending on architectures and even
>>>> depending on the glibc versions. Which is why we took 32 Kb as the
>>>> default stack size. Since the default is enough even for struct xnsig,
>>>> if you are asking a smaller size, you may have good reasons to do so. We
>>>> should check that the size is at least sizeof(struct xnsig), but since
>>>> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
>>>>
>>>> The point is that your system seems to require 16 Kb whereas
>>>> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
>>>> else.
>>>>
>>>> Could you run the segfaulting program inside gdb, and print the frames
>>>> infos ?
>>> gdb logfile attached
>> Ok. Could you get the value of the "esp" register at the time of the
>> failure, as well as the contents of /proc/<pid>/smaps where <pid> is the
>> pid of the failing application ? You can run the cat /proc/<pid>/smaps
>> when the process is stopped in gdb.

How much is PTHREAD_STACK_MIN on your system by the way ?

-- 
					    Gilles.

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

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

Am 08.01.2010 14:54, schrieb Gilles Chanteperdrix:
> Stefan Kisdaroczi wrote:
>> Am 08.01.2010 14:30, schrieb Gilles Chanteperdrix:
>>> Stefan Kisdaroczi wrote:
>>>> Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
>>>>> Stefan Kisdaroczi wrote:
>>>>>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>>>> hi,
>>>>>>>>>>
>>>>>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>>>>>> xenomai trivial-periodic.c example:
>>>>>>>>>>
>>>>>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>>>>>
>>>>>>>>>> Stacksize 0 -> default stack size : ok
>>>>>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>>>>>> Stacksize >= 16912 : ok
>>>>>>>>>>
>>>>>>>>>> Any hints ?
>>>>>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>>>>>> the stack.
>>>>>>>>>
>>>>>>>> To clarify:
>>>>>>>> It does not depend on the task body, the task is not even started.
>>>>>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>>>>>> is called.
>>>>>>> Actually, when calling rt_task_create, the thread is created, under the
>>>>>>> hood, and waits to be started. So the segmentation fault is most
>>>>>>> certainly due to a stack overflow in the newly created thread.
>>>>>>>
>>>>>>> And I am afraid I know why it happens: the newly merged user-space
>>>>>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>>>>>> But this amounts to two Kbytes here. Could you run the following program
>>>>>>> on your target ?
>>>>>> salut gilles,
>>>>>>
>>>>>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>>>>>> the value is too small, i suggest to take the stacksize needed by xenomai
>>>>>> into account too. The attached patch is clearly wrong, but it solved the
>>>>>> problem for me.
>>>>> PTHREAD_STACK_MIN varies a lot depending on architectures and even
>>>>> depending on the glibc versions. Which is why we took 32 Kb as the
>>>>> default stack size. Since the default is enough even for struct xnsig,
>>>>> if you are asking a smaller size, you may have good reasons to do so. We
>>>>> should check that the size is at least sizeof(struct xnsig), but since
>>>>> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
>>>>>
>>>>> The point is that your system seems to require 16 Kb whereas
>>>>> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
>>>>> else.
>>>>>
>>>>> Could you run the segfaulting program inside gdb, and print the frames
>>>>> infos ?
>>>> gdb logfile attached
>>> Ok. Could you get the value of the "esp" register at the time of the
>>> failure, as well as the contents of /proc/<pid>/smaps where <pid> is the
>>> pid of the failing application ? You can run the cat /proc/<pid>/smaps
>>> when the process is stopped in gdb.
> 
> How much is PTHREAD_STACK_MIN on your system by the way ?
> 

16 kbyte defined in /usr/include/bits/local_lim.h


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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

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

Am 08.01.2010 14:59, schrieb Stefan Kisdaroczi:
> Am 08.01.2010 14:54, schrieb Gilles Chanteperdrix:
>> Stefan Kisdaroczi wrote:
>>> Am 08.01.2010 14:30, schrieb Gilles Chanteperdrix:
>>>> Stefan Kisdaroczi wrote:
>>>>> Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
>>>>>> Stefan Kisdaroczi wrote:
>>>>>>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>>>>> hi,
>>>>>>>>>>>
>>>>>>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>>>>>>> xenomai trivial-periodic.c example:
>>>>>>>>>>>
>>>>>>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>>>>>>
>>>>>>>>>>> Stacksize 0 -> default stack size : ok
>>>>>>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>>>>>>> Stacksize >= 16912 : ok
>>>>>>>>>>>
>>>>>>>>>>> Any hints ?
>>>>>>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>>>>>>> the stack.
>>>>>>>>>>
>>>>>>>>> To clarify:
>>>>>>>>> It does not depend on the task body, the task is not even started.
>>>>>>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>>>>>>> is called.
>>>>>>>> Actually, when calling rt_task_create, the thread is created, under the
>>>>>>>> hood, and waits to be started. So the segmentation fault is most
>>>>>>>> certainly due to a stack overflow in the newly created thread.
>>>>>>>>
>>>>>>>> And I am afraid I know why it happens: the newly merged user-space
>>>>>>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>>>>>>> But this amounts to two Kbytes here. Could you run the following program
>>>>>>>> on your target ?
>>>>>>> salut gilles,
>>>>>>>
>>>>>>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>>>>>>> the value is too small, i suggest to take the stacksize needed by xenomai
>>>>>>> into account too. The attached patch is clearly wrong, but it solved the
>>>>>>> problem for me.
>>>>>> PTHREAD_STACK_MIN varies a lot depending on architectures and even
>>>>>> depending on the glibc versions. Which is why we took 32 Kb as the
>>>>>> default stack size. Since the default is enough even for struct xnsig,
>>>>>> if you are asking a smaller size, you may have good reasons to do so. We
>>>>>> should check that the size is at least sizeof(struct xnsig), but since
>>>>>> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
>>>>>>
>>>>>> The point is that your system seems to require 16 Kb whereas
>>>>>> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
>>>>>> else.
>>>>>>
>>>>>> Could you run the segfaulting program inside gdb, and print the frames
>>>>>> infos ?
>>>>> gdb logfile attached
>>>> Ok. Could you get the value of the "esp" register at the time of the
>>>> failure, as well as the contents of /proc/<pid>/smaps where <pid> is the
>>>> pid of the failing application ? You can run the cat /proc/<pid>/smaps
>>>> when the process is stopped in gdb.
>>
>> How much is PTHREAD_STACK_MIN on your system by the way ?
>>
> 
> 16 kbyte defined in /usr/include/bits/local_lim.h

I still think that the idea behind my patch was not so bad and that the
problem is simply because the value is calculated to small.

I have found the following sentence at [1] & [2]:
"You can get the absolute minimum limit on stack size by calling the macro
PTHREAD_STACK_MIN, which returns the amount of stack space required for a
thread that executes a NULL procedure."

As the xnsig structure needs 2k on the stack, its not a "NULL procedure".
For me that means that if _my_ main task function is a "NULL procedure",
I need at least PTHREAD_STACK_MIN + XN_STACK_MIN.
XN_STACK_MIN = sizeof(xnsig) + ? -> 4k ?

Finally, as I don't know and dont want to know that values in my app,
and they can change with newer glibc's and xenomai, I think the minimal
stacksize should be calculated like this ( if stksize != 0 ) :

  stacksize = PTHREAD_STACK_MIN + XN_STACK_MIN + stksize;

This way, my main task function has always the same free stacksize when
called, and I know how much I need (at least I think I know ;-). If it
still segfaults, its in my code and its my fault.

But I may be completely wrong.
kisda

[1] http://nortul.com/linux/C_language_adv/node30.html
[2] http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWdev/MTP/p18.html


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

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Gilles Chanteperdrix]

Stefan Kisdaroczi wrote:
> Am 08.01.2010 14:59, schrieb Stefan Kisdaroczi:
>> Am 08.01.2010 14:54, schrieb Gilles Chanteperdrix:
>>> Stefan Kisdaroczi wrote:
>>>> Am 08.01.2010 14:30, schrieb Gilles Chanteperdrix:
>>>>> Stefan Kisdaroczi wrote:
>>>>>> Am 08.01.2010 12:57, schrieb Gilles Chanteperdrix:
>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>> Am 07.01.2010 17:57, schrieb Gilles Chanteperdrix:
>>>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>>>> Am 07.01.2010 15:36, schrieb Gilles Chanteperdrix:
>>>>>>>>>>> Stefan Kisdaroczi wrote:
>>>>>>>>>>>> hi,
>>>>>>>>>>>>
>>>>>>>>>>>> i have upgraded xenomai to 2.5.0 (x86,32bit). My application segfaults when I
>>>>>>>>>>>> try to create a task with stacksize 2048, this worked with 2.4.10.
>>>>>>>>>>>> Because my app is written in pascal i have reproduced the problem with the
>>>>>>>>>>>> xenomai trivial-periodic.c example:
>>>>>>>>>>>>
>>>>>>>>>>>> -	rt_task_create(&demo_task, "trivial", 0, 99, 0);
>>>>>>>>>>>> +	rt_task_create(&demo_task, "trivial",16911, 99, 0);
>>>>>>>>>>>>
>>>>>>>>>>>> Stacksize 0 -> default stack size : ok
>>>>>>>>>>>> Stacksize > 0 and <= 16911 : Segmentation fault
>>>>>>>>>>>> Stacksize >= 16912 : ok
>>>>>>>>>>>>
>>>>>>>>>>>> Any hints ?
>>>>>>>>>>> What does the task do? If it uses printf, printf needs a lot of room on
>>>>>>>>>>> the stack.
>>>>>>>>>>>
>>>>>>>>>> To clarify:
>>>>>>>>>> It does not depend on the task body, the task is not even started.
>>>>>>>>>> The segfault happens when calling rt_task_create(), before rt_task_start()
>>>>>>>>>> is called.
>>>>>>>>> Actually, when calling rt_task_create, the thread is created, under the
>>>>>>>>> hood, and waits to be started. So the segmentation fault is most
>>>>>>>>> certainly due to a stack overflow in the newly created thread.
>>>>>>>>>
>>>>>>>>> And I am afraid I know why it happens: the newly merged user-space
>>>>>>>>> signals support requires roughly 16 * sizeof(struct siginfo) on stack.
>>>>>>>>> But this amounts to two Kbytes here. Could you run the following program
>>>>>>>>> on your target ?
>>>>>>>> salut gilles,
>>>>>>>>
>>>>>>>> as the stacksize is already checked and increased to PTHREAD_STACK_MIN if
>>>>>>>> the value is too small, i suggest to take the stacksize needed by xenomai
>>>>>>>> into account too. The attached patch is clearly wrong, but it solved the
>>>>>>>> problem for me.
>>>>>>> PTHREAD_STACK_MIN varies a lot depending on architectures and even
>>>>>>> depending on the glibc versions. Which is why we took 32 Kb as the
>>>>>>> default stack size. Since the default is enough even for struct xnsig,
>>>>>>> if you are asking a smaller size, you may have good reasons to do so. We
>>>>>>> should check that the size is at least sizeof(struct xnsig), but since
>>>>>>> PTHREAD_STACK_MIN is larger than struct xnsig, it should work as is.
>>>>>>>
>>>>>>> The point is that your system seems to require 16 Kb whereas
>>>>>>> sizeof(struct xnsig) is only 2Kb. So, there is something wrong somewhere
>>>>>>> else.
>>>>>>>
>>>>>>> Could you run the segfaulting program inside gdb, and print the frames
>>>>>>> infos ?
>>>>>> gdb logfile attached
>>>>> Ok. Could you get the value of the "esp" register at the time of the
>>>>> failure, as well as the contents of /proc/<pid>/smaps where <pid> is the
>>>>> pid of the failing application ? You can run the cat /proc/<pid>/smaps
>>>>> when the process is stopped in gdb.
>>> How much is PTHREAD_STACK_MIN on your system by the way ?
>>>
>> 16 kbyte defined in /usr/include/bits/local_lim.h
> 
> I still think that the idea behind my patch was not so bad and that the
> problem is simply because the value is calculated to small.
> 
> I have found the following sentence at [1] & [2]:
> "You can get the absolute minimum limit on stack size by calling the macro
> PTHREAD_STACK_MIN, which returns the amount of stack space required for a
> thread that executes a NULL procedure."
> 
> As the xnsig structure needs 2k on the stack, its not a "NULL procedure".
> For me that means that if _my_ main task function is a "NULL procedure",
> I need at least PTHREAD_STACK_MIN + XN_STACK_MIN.
> XN_STACK_MIN = sizeof(xnsig) + ? -> 4k ?
> 
> Finally, as I don't know and dont want to know that values in my app,
> and they can change with newer glibc's and xenomai, I think the minimal
> stacksize should be calculated like this ( if stksize != 0 ) :
> 
>   stacksize = PTHREAD_STACK_MIN + XN_STACK_MIN + stksize;
> 
> This way, my main task function has always the same free stacksize when
> called, and I know how much I need (at least I think I know ;-). If it
> still segfaults, its in my code and its my fault.
> 
> But I may be completely wrong.

No. I think you are right, we will make the minimum PTHREAD_STACK_MIN +
getpagesize() to account for differences between architectures.

Patch will come soon.

-- 
					    Gilles.

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> No. I think you are right, we will make the minimum PTHREAD_STACK_MIN +
> getpagesize() to account for differences between architectures.
> 
> Patch will come soon.

Here it comes.

diff --git a/include/asm-generic/stacksize.h b/include/asm-generic/stacksize.h
new file mode 100644
index 0000000..f82f390
--- /dev/null
+++ b/include/asm-generic/stacksize.h
@@ -0,0 +1,30 @@
+#ifndef STACKSIZE_H
+#define STACKSIZE_H
+
+#include <stdint.h>
+#include <pthread.h>
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+static inline unsigned xeno_stacksize(unsigned size)
+{
+	static const unsigned default_size = __WORDSIZE * 1024;
+	static unsigned min_size;
+	if (!min_size)
+		min_size = PTHREAD_STACK_MIN + getpagesize();
+
+	if (!size)
+		size = default_size;
+	if (size < min_size)
+		size = min_size;
+
+	return size;
+}
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* STACKSIZE_H */
diff --git a/src/rtdk/rt_print.c b/src/rtdk/rt_print.c
index c6b5c55..1d2b70a 100644
--- a/src/rtdk/rt_print.c
+++ b/src/rtdk/rt_print.c
@@ -455,7 +455,7 @@ static void spawn_printer_thread(void)
 	pthread_attr_t thattr;
 
 	pthread_attr_init(&thattr);
-	pthread_attr_setstacksize(&thattr, PTHREAD_STACK_MIN);
+	pthread_attr_setstacksize(&thattr, xeno_stacksize(0));
 	pthread_create(&printer_thread, &thattr, printer_loop, NULL);
 }
 
diff --git a/src/skins/native/task.c b/src/skins/native/task.c
index f6c2de9..341e4d8 100644
--- a/src/skins/native/task.c
+++ b/src/skins/native/task.c
@@ -28,6 +28,7 @@
 #include <native/task.h>
 #include <asm-generic/bits/sigshadow.h>
 #include <asm-generic/bits/current.h>
+#include <asm-generic/stacksize.h>
 #include "wrappers.h"
 
 #ifdef HAVE___THREAD
@@ -146,10 +147,7 @@ int rt_task_create(RT_TASK *task,
 
 	pthread_attr_init(&thattr);
 
-	if (!stksize)
-		stksize = 32 * 1024;
-	if (stksize < PTHREAD_STACK_MIN)
-		stksize = PTHREAD_STACK_MIN;
+	stksize = xeno_stacksize(stksize);
 
 	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
 	memset(&param, 0, sizeof(param));
diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
index 7a8d012..9115a58 100644
--- a/src/skins/posix/thread.c
+++ b/src/skins/posix/thread.c
@@ -28,6 +28,7 @@
 #include <posix/syscall.h>
 #include <asm-generic/bits/current.h>
 #include <asm-generic/bits/sigshadow.h>
+#include <asm-generic/stacksize.h>
 
 extern int __pse51_muxid;
 
@@ -244,10 +245,11 @@ int __wrap_pthread_create(pthread_t *tid,
 			  void *(*start) (void *), void *arg)
 {
 	struct pthread_iargs iargs;
+	struct sched_param param;
 	pthread_attr_t iattr;
 	int inherit, err;
-	struct sched_param param;
 	pthread_t ltid;
+	unsigned stksz;
 
 	if (!attr)
 		attr = &default_attr;
@@ -274,6 +276,8 @@ int __wrap_pthread_create(pthread_t *tid,
 		/* Get the created thread to temporarily inherit pthread_create
 		   caller priority */
 		pthread_attr_setinheritsched(&iattr, PTHREAD_INHERIT_SCHED);
+	pthread_attr_getstacksize(&iattr, &stksz);
+	pthread_attr_setstacksize(&iattr, xeno_stacksize(stksz));
 	attr = &iattr;
 
 	/* First start a native POSIX thread, then associate a Xenomai shadow to
diff --git a/src/skins/psos+/task.c b/src/skins/psos+/task.c
index d9b0a1e..b5f36d2 100644
--- a/src/skins/psos+/task.c
+++ b/src/skins/psos+/task.c
@@ -28,6 +28,7 @@
 #include <psos+/psos.h>
 #include <asm-generic/bits/sigshadow.h>
 #include <asm-generic/bits/current.h>
+#include <asm-generic/stacksize.h>
 
 extern int __psos_muxid;
 
@@ -141,10 +142,7 @@ u_long t_create(const char *name,
 
 	ustack += sstack;
 
-	if (ustack == 0)
-		ustack = PTHREAD_STACK_MIN * 4;
-	else if (ustack < PTHREAD_STACK_MIN * 2)
-		ustack = PTHREAD_STACK_MIN * 2;
+	ustack = xeno_stacksize(ustack);
 
 	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
 	policy = psos_task_set_posix_priority(prio, &param);
diff --git a/src/skins/uitron/task.c b/src/skins/uitron/task.c
index e7468c7..69022c2 100644
--- a/src/skins/uitron/task.c
+++ b/src/skins/uitron/task.c
@@ -127,10 +127,7 @@ ER cre_tsk(ID tskid, T_CTSK *pk_ctsk)
 
 	pthread_attr_init(&thattr);
 
-	if (pk_ctsk->stksz == 0)
-		pk_ctsk->stksz = PTHREAD_STACK_MIN * 4;
-	else if (pk_ctsk->stksz < PTHREAD_STACK_MIN * 2)
-		pk_ctsk->stksz = PTHREAD_STACK_MIN * 2;
+	pk_ctsk->stksz = xeno_stacksize(pk_ctsk->stksz);
 
 	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
 	policy = uitron_task_set_posix_priority(pk_ctsk->itskpri, &param);
diff --git a/src/skins/vrtx/task.c b/src/skins/vrtx/task.c
index c835db0..8b9e051 100644
--- a/src/skins/vrtx/task.c
+++ b/src/skins/vrtx/task.c
@@ -31,6 +31,7 @@
 #include <vrtx/vrtx.h>
 #include <asm-generic/bits/sigshadow.h>
 #include <asm-generic/bits/current.h>
+#include <asm-generic/stacksize.h>
 #include "wrappers.h"
 
 #ifdef HAVE___THREAD
@@ -150,10 +151,7 @@ int sc_tecreate(void (*entry) (void *),
 
 	pthread_attr_init(&thattr);
 
-	if (ustacksz == 0)
-		ustacksz = PTHREAD_STACK_MIN * 4;
-	else if (ustacksz < PTHREAD_STACK_MIN * 2)
-		ustacksz = PTHREAD_STACK_MIN * 2;
+	ustacksz = xeno_stacksize(ustacksz);
 
 	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
 	policy = vrtx_task_set_posix_priority(prio, &param);
diff --git a/src/skins/vxworks/taskLib.c b/src/skins/vxworks/taskLib.c
index 3249bfc..6b118e7 100644
--- a/src/skins/vxworks/taskLib.c
+++ b/src/skins/vxworks/taskLib.c
@@ -30,6 +30,7 @@
 #include <vxworks/vxworks.h>
 #include <asm-generic/bits/sigshadow.h>
 #include <asm-generic/bits/current.h>
+#include <asm-generic/stacksize.h>
 #include "wrappers.h"
 
 #ifdef HAVE___THREAD
@@ -184,10 +185,7 @@ STATUS taskInit(WIND_TCB *pTcb,
 
 	pthread_attr_init(&thattr);
 
-	if (stacksize == 0)
-		stacksize = PTHREAD_STACK_MIN * 4;
-	else if (stacksize < PTHREAD_STACK_MIN * 2)
-		stacksize = PTHREAD_STACK_MIN * 2;
+	stacksize = xeno_stacksize(stacksize);
 
 	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
 	policy = wind_task_set_posix_priority(prio, &param);
diff --git a/src/testsuite/switchtest/switchtest.c b/src/testsuite/switchtest/switchtest.c
index 66d0eab..b1cb728 100644
--- a/src/testsuite/switchtest/switchtest.c
+++ b/src/testsuite/switchtest/switchtest.c
@@ -17,6 +17,7 @@
 
 #include <xeno_config.h>
 #include <asm/xenomai/fptest.h>
+#include <asm-generic/stacksize.h>
 #include <nucleus/trace.h>
 #include <rtdm/rttesting.h>
 
@@ -43,17 +44,8 @@ typedef unsigned long cpu_set_t;
 #define smp_sched_setaffinity(pid,len,mask) 0
 #endif /* !CONFIG_SMP */
 
-#if PTHREAD_STACK_MIN < 20 * 1024
-#define SMALL_STACK_MIN  20 * 1024
-#else
-#define SMALL_STACK_MIN  PTHREAD_STACK_MIN
-#endif
-
-#if PTHREAD_STACK_MIN < 50 * 1024
-#define LARGE_STACK_MIN  50 * 1024
-#else
-#define LARGE_STACK_MIN  PTHREAD_STACK_MIN
-#endif
+#define SMALL_STACK_MIN xeno_stacksize(20 * 1024)
+#define LARGE_STACK_MIN xeno_stacksize(50 * 1024)
 
 /* Thread type. */
 typedef enum {


-- 
					    Gilles.

Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small

[Stefan Kisdaroczi]

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

Am 08.01.2010 23:37, schrieb Gilles Chanteperdrix:
> Gilles Chanteperdrix wrote:
>> No. I think you are right, we will make the minimum PTHREAD_STACK_MIN +
>> getpagesize() to account for differences between architectures.
>>
>> Patch will come soon.
> 
> Here it comes.

Works fine, thank you. Stefan


> diff --git a/include/asm-generic/stacksize.h b/include/asm-generic/stacksize.h
> new file mode 100644
> index 0000000..f82f390
> --- /dev/null
> +++ b/include/asm-generic/stacksize.h
> @@ -0,0 +1,30 @@
> +#ifndef STACKSIZE_H
> +#define STACKSIZE_H
> +
> +#include <stdint.h>
> +#include <pthread.h>
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif /* __cplusplus */
> +
> +static inline unsigned xeno_stacksize(unsigned size)
> +{
> +	static const unsigned default_size = __WORDSIZE * 1024;
> +	static unsigned min_size;
> +	if (!min_size)
> +		min_size = PTHREAD_STACK_MIN + getpagesize();
> +
> +	if (!size)
> +		size = default_size;
> +	if (size < min_size)
> +		size = min_size;
> +
> +	return size;
> +}
> +
> +#ifdef __cplusplus
> +}
> +#endif /* __cplusplus */
> +
> +#endif /* STACKSIZE_H */
> diff --git a/src/rtdk/rt_print.c b/src/rtdk/rt_print.c
> index c6b5c55..1d2b70a 100644
> --- a/src/rtdk/rt_print.c
> +++ b/src/rtdk/rt_print.c
> @@ -455,7 +455,7 @@ static void spawn_printer_thread(void)
>  	pthread_attr_t thattr;
>  
>  	pthread_attr_init(&thattr);
> -	pthread_attr_setstacksize(&thattr, PTHREAD_STACK_MIN);
> +	pthread_attr_setstacksize(&thattr, xeno_stacksize(0));
>  	pthread_create(&printer_thread, &thattr, printer_loop, NULL);
>  }
>  
> diff --git a/src/skins/native/task.c b/src/skins/native/task.c
> index f6c2de9..341e4d8 100644
> --- a/src/skins/native/task.c
> +++ b/src/skins/native/task.c
> @@ -28,6 +28,7 @@
>  #include <native/task.h>
>  #include <asm-generic/bits/sigshadow.h>
>  #include <asm-generic/bits/current.h>
> +#include <asm-generic/stacksize.h>
>  #include "wrappers.h"
>  
>  #ifdef HAVE___THREAD
> @@ -146,10 +147,7 @@ int rt_task_create(RT_TASK *task,
>  
>  	pthread_attr_init(&thattr);
>  
> -	if (!stksize)
> -		stksize = 32 * 1024;
> -	if (stksize < PTHREAD_STACK_MIN)
> -		stksize = PTHREAD_STACK_MIN;
> +	stksize = xeno_stacksize(stksize);
>  
>  	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
>  	memset(&param, 0, sizeof(param));
> diff --git a/src/skins/posix/thread.c b/src/skins/posix/thread.c
> index 7a8d012..9115a58 100644
> --- a/src/skins/posix/thread.c
> +++ b/src/skins/posix/thread.c
> @@ -28,6 +28,7 @@
>  #include <posix/syscall.h>
>  #include <asm-generic/bits/current.h>
>  #include <asm-generic/bits/sigshadow.h>
> +#include <asm-generic/stacksize.h>
>  
>  extern int __pse51_muxid;
>  
> @@ -244,10 +245,11 @@ int __wrap_pthread_create(pthread_t *tid,
>  			  void *(*start) (void *), void *arg)
>  {
>  	struct pthread_iargs iargs;
> +	struct sched_param param;
>  	pthread_attr_t iattr;
>  	int inherit, err;
> -	struct sched_param param;
>  	pthread_t ltid;
> +	unsigned stksz;
>  
>  	if (!attr)
>  		attr = &default_attr;
> @@ -274,6 +276,8 @@ int __wrap_pthread_create(pthread_t *tid,
>  		/* Get the created thread to temporarily inherit pthread_create
>  		   caller priority */
>  		pthread_attr_setinheritsched(&iattr, PTHREAD_INHERIT_SCHED);
> +	pthread_attr_getstacksize(&iattr, &stksz);
> +	pthread_attr_setstacksize(&iattr, xeno_stacksize(stksz));
>  	attr = &iattr;
>  
>  	/* First start a native POSIX thread, then associate a Xenomai shadow to
> diff --git a/src/skins/psos+/task.c b/src/skins/psos+/task.c
> index d9b0a1e..b5f36d2 100644
> --- a/src/skins/psos+/task.c
> +++ b/src/skins/psos+/task.c
> @@ -28,6 +28,7 @@
>  #include <psos+/psos.h>
>  #include <asm-generic/bits/sigshadow.h>
>  #include <asm-generic/bits/current.h>
> +#include <asm-generic/stacksize.h>
>  
>  extern int __psos_muxid;
>  
> @@ -141,10 +142,7 @@ u_long t_create(const char *name,
>  
>  	ustack += sstack;
>  
> -	if (ustack == 0)
> -		ustack = PTHREAD_STACK_MIN * 4;
> -	else if (ustack < PTHREAD_STACK_MIN * 2)
> -		ustack = PTHREAD_STACK_MIN * 2;
> +	ustack = xeno_stacksize(ustack);
>  
>  	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
>  	policy = psos_task_set_posix_priority(prio, &param);
> diff --git a/src/skins/uitron/task.c b/src/skins/uitron/task.c
> index e7468c7..69022c2 100644
> --- a/src/skins/uitron/task.c
> +++ b/src/skins/uitron/task.c
> @@ -127,10 +127,7 @@ ER cre_tsk(ID tskid, T_CTSK *pk_ctsk)
>  
>  	pthread_attr_init(&thattr);
>  
> -	if (pk_ctsk->stksz == 0)
> -		pk_ctsk->stksz = PTHREAD_STACK_MIN * 4;
> -	else if (pk_ctsk->stksz < PTHREAD_STACK_MIN * 2)
> -		pk_ctsk->stksz = PTHREAD_STACK_MIN * 2;
> +	pk_ctsk->stksz = xeno_stacksize(pk_ctsk->stksz);
>  
>  	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
>  	policy = uitron_task_set_posix_priority(pk_ctsk->itskpri, &param);
> diff --git a/src/skins/vrtx/task.c b/src/skins/vrtx/task.c
> index c835db0..8b9e051 100644
> --- a/src/skins/vrtx/task.c
> +++ b/src/skins/vrtx/task.c
> @@ -31,6 +31,7 @@
>  #include <vrtx/vrtx.h>
>  #include <asm-generic/bits/sigshadow.h>
>  #include <asm-generic/bits/current.h>
> +#include <asm-generic/stacksize.h>
>  #include "wrappers.h"
>  
>  #ifdef HAVE___THREAD
> @@ -150,10 +151,7 @@ int sc_tecreate(void (*entry) (void *),
>  
>  	pthread_attr_init(&thattr);
>  
> -	if (ustacksz == 0)
> -		ustacksz = PTHREAD_STACK_MIN * 4;
> -	else if (ustacksz < PTHREAD_STACK_MIN * 2)
> -		ustacksz = PTHREAD_STACK_MIN * 2;
> +	ustacksz = xeno_stacksize(ustacksz);
>  
>  	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
>  	policy = vrtx_task_set_posix_priority(prio, &param);
> diff --git a/src/skins/vxworks/taskLib.c b/src/skins/vxworks/taskLib.c
> index 3249bfc..6b118e7 100644
> --- a/src/skins/vxworks/taskLib.c
> +++ b/src/skins/vxworks/taskLib.c
> @@ -30,6 +30,7 @@
>  #include <vxworks/vxworks.h>
>  #include <asm-generic/bits/sigshadow.h>
>  #include <asm-generic/bits/current.h>
> +#include <asm-generic/stacksize.h>
>  #include "wrappers.h"
>  
>  #ifdef HAVE___THREAD
> @@ -184,10 +185,7 @@ STATUS taskInit(WIND_TCB *pTcb,
>  
>  	pthread_attr_init(&thattr);
>  
> -	if (stacksize == 0)
> -		stacksize = PTHREAD_STACK_MIN * 4;
> -	else if (stacksize < PTHREAD_STACK_MIN * 2)
> -		stacksize = PTHREAD_STACK_MIN * 2;
> +	stacksize = xeno_stacksize(stacksize);
>  
>  	pthread_attr_setinheritsched(&thattr, PTHREAD_EXPLICIT_SCHED);
>  	policy = wind_task_set_posix_priority(prio, &param);
> diff --git a/src/testsuite/switchtest/switchtest.c b/src/testsuite/switchtest/switchtest.c
> index 66d0eab..b1cb728 100644
> --- a/src/testsuite/switchtest/switchtest.c
> +++ b/src/testsuite/switchtest/switchtest.c
> @@ -17,6 +17,7 @@
>  
>  #include <xeno_config.h>
>  #include <asm/xenomai/fptest.h>
> +#include <asm-generic/stacksize.h>
>  #include <nucleus/trace.h>
>  #include <rtdm/rttesting.h>
>  
> @@ -43,17 +44,8 @@ typedef unsigned long cpu_set_t;
>  #define smp_sched_setaffinity(pid,len,mask) 0
>  #endif /* !CONFIG_SMP */
>  
> -#if PTHREAD_STACK_MIN < 20 * 1024
> -#define SMALL_STACK_MIN  20 * 1024
> -#else
> -#define SMALL_STACK_MIN  PTHREAD_STACK_MIN
> -#endif
> -
> -#if PTHREAD_STACK_MIN < 50 * 1024
> -#define LARGE_STACK_MIN  50 * 1024
> -#else
> -#define LARGE_STACK_MIN  PTHREAD_STACK_MIN
> -#endif
> +#define SMALL_STACK_MIN xeno_stacksize(20 * 1024)
> +#define LARGE_STACK_MIN xeno_stacksize(50 * 1024)
>  
>  /* Thread type. */
>  typedef enum {
> 
> 



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