From: Stefan Kisdaroczi <kisda@domain.hid>
To: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small
Date: Fri, 08 Jan 2010 14:24:22 +0100 [thread overview]
Message-ID: <4B473206.90209@domain.hid> (raw)
In-Reply-To: <4B471D96.7050001@domain.hid>
[-- 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 --]
next prev parent reply other threads:[~2010-01-08 13:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-07 14:32 [Xenomai-help] native skin 2.5.0: rt_task_create() segfaults if stacksize parameter too small Stefan Kisdaroczi
2010-01-07 14:36 ` Gilles Chanteperdrix
2010-01-07 14:55 ` Stefan Kisdaroczi
2010-01-07 15:48 ` Stefan Kisdaroczi
2010-01-07 16:57 ` Gilles Chanteperdrix
2010-01-07 17:26 ` Stefan Kisdaroczi
2010-01-08 11:47 ` Stefan Kisdaroczi
2010-01-08 11:57 ` Gilles Chanteperdrix
2010-01-08 13:24 ` Stefan Kisdaroczi [this message]
2010-01-08 13:30 ` Gilles Chanteperdrix
2010-01-08 13:41 ` Stefan Kisdaroczi
2010-01-08 13:52 ` Gilles Chanteperdrix
2010-01-08 14:07 ` Stefan Kisdaroczi
2010-01-08 13:54 ` Gilles Chanteperdrix
2010-01-08 13:59 ` Stefan Kisdaroczi
2010-01-08 15:57 ` Stefan Kisdaroczi
2010-01-08 17:12 ` Gilles Chanteperdrix
2010-01-08 22:37 ` Gilles Chanteperdrix
2010-01-11 10:53 ` Stefan Kisdaroczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B473206.90209@domain.hid \
--to=kisda@domain.hid \
--cc=gilles.chanteperdrix@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.