From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4B476768.2080502@domain.hid> Date: Fri, 08 Jan 2010 18:12:08 +0100 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <4B45F088.9010603@domain.hid> <4B45F163.4000504@domain.hid> <4B460255.30200@domain.hid> <4B46125D.4010602@domain.hid> <4B471B48.6040301@domain.hid> <4B471D96.7050001@domain.hid> <4B473206.90209@domain.hid> <4B47338E.9080304@domain.hid> <4B4735F4.6060503@domain.hid> <4B4738FE.4020605@domain.hid> <4B473A59.4090905@domain.hid> <4B4755DA.3060201@domain.hid> In-Reply-To: <4B4755DA.3060201@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Kisdaroczi Cc: xenomai@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//smaps where is the >>>>> pid of the failing application ? You can run the cat /proc//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.