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

[Stefan Kisdaroczi <kisda@domain.hid>]

[-- 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 --]