From: Jan Kiszka <jan.kiszka@domain.hid>
To: "Ignacio García Pérez" <iggarpe@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Strange segmentation fault
Date: Thu, 07 Sep 2006 12:44:38 +0200 [thread overview]
Message-ID: <44FFF816.6010105@domain.hid> (raw)
In-Reply-To: <44FFF19B.8080104@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 3456 bytes --]
Ignacio García Pérez wrote:
> Hi,
>
> I'm experiencing an strange segmentation fault problem. I've boiled down
> the code to the simplest possible program that causes the segfault:
>
> 1- Set the timer in oneshot mode.
> 2- Create a task.
> 3- Start the task.
>
> At the task function:
>
> 1- Make the task periodic (1s).
> 2- Issue a fprintf.
>
> That's all. The code segfaults. If I remove the fprintf, it won't
> segfault. If I change it for a printf, it won't segfault.
>
> If I use fprintf but print just "TICK" instead of "TICK %u", it won't
> segfault while the task is running, but it will when the program is
> interrupted (not shown here, but I tried this with a signal handler in
> place that properly deleted the task, though I think this is not
> absolutely necessary).
>
> I'm totally confused.
>
> I know I can use fprintf as long as I assume that the RT task will go
> into "secondary" mode at this point because it'll be using linux
> services, and that it will go back to "primary" RT mode on the next call
> to rt_task_wait_period.
>
> Also, I know that it would be best to use periodic instead of oneshot
> mode, but my program is obviously more complex than this boiled down
> example and really needs oneshot mode.
>
> Any ideas about what could be the problem?
>
> Thanks.
>
> P.S: This is the same problem I described earlier inthe list as caused
> by inb. I though that inb was the cause because removing it avoided the
> segfault, however, it turns out that removing the inb was causing
> another piece of code containing the fprintf not to execute.
>
> //===========================================================================
>
>
> #include <sys/types.h>
> #include <sys/mman.h>
> #include <sys/io.h>
> #include <unistd.h>
> #include <stdlib.h>
> #include <stdio.h>
>
> #include <native/task.h>
>
> #include "main.h"
>
>
>
> static RT_TASK _io_task;
>
> static void _io_proc (void *arg) {
>
> u_long overrun;
>
> rt_task_set_periodic(&_io_task, TM_NOW,
> rt_timer_ns2ticks(1000000000LL));
>
> for (;;) {
>
> rt_task_wait_period(&overrun);
>
> fprintf(stderr, "TICK %u\n", 1);
> }
> }
>
>
>
> static void _cleanup (void) {
> rt_task_delete(&_io_task);
> }
>
>
>
> static int _init (void) {
>
> int r;
>
> r = rt_timer_set_mode(TM_ONESHOT);
> if (r < 0) {
> fprintf(stderr, "ERROR %i initializing RT\n", r);
> _cleanup(); return r;
> }
>
> r = rt_task_create(&_io_task, "rtcore_io_task", 0x1000, 10, T_FPU);
Try PTHREAD_STACK_MIN instead of 0x1000 - or, better, leave it 0 and let
Xenomai pick a value for you. Unless you need more than the default
stack (PTHREAD_STACK_MIN * 4) or you are *sure* to get a way with
PTHREAD_STACK_MIN, you should avoid touching this value.
> if (r < 0) {
> fprintf(stderr, "ERROR %i creating task\n", r);
> _cleanup(); return r;
> }
>
> r = rt_task_start(&_io_task, &_io_proc, NULL);
> if (r < 0) {
> fprintf(stderr, "ERROR %i starting task\n", r);
> _cleanup(); return r;
> }
>
> return 0;
> }
>
>
>
> int main (int argc, char **argv) {
>
> iopl(3);
> mlockall(MCL_CURRENT | MCL_FUTURE);
>
> if ( _init() < 0) return 1;
>
> for (;;) sleep(1);
>
> _cleanup();
>
> return 0;
> }
>
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
next prev parent reply other threads:[~2006-09-07 10:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-07 10:16 [Xenomai-help] Strange segmentation fault Ignacio García Pérez
2006-09-07 10:44 ` Jan Kiszka [this message]
2006-09-07 11:03 ` Gilles Chanteperdrix
2006-09-11 9:27 ` Ignacio García Pérez
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=44FFF816.6010105@domain.hid \
--to=jan.kiszka@domain.hid \
--cc=iggarpe@domain.hid \
--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.