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

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

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.