Re: [Xenomai-help] Segmentation fault in rt_printf print thread

[Christoph Permes <christoph.permes@domain.hid>]

Hi,

I have examined the print_buffers() function and my core dump:

#1  0xb8087f61 in print_buffers () at rt_print.c:380
380				fprintf(head->dest, "%s", head->text);
(gdb) print head->dest
$1 = (FILE *) 0x445b205d
(gdb) print head->text
$2 = "_"
(gdb) print (char*)head
$3 = 0x8ea5a02 "] [D] [V_MainClampToteRequest   ] ===> [1]\n"
(gdb) print buffer->read_pos
$4 = 3482
(gdb) print *(char*)buffer->ring@domain.hid
$5 = "... [67046.506] [CONTROL] [1104820] [\000] [D] [V_MainClamp"

As the above output shows the head pointer points to a wrong memory
address, the head->dest FILE pointer results from some text written to
the buffer.

buffer = get_next_buffer();
if (!buffer)
        break;

read_pos = buffer->read_pos;
head = buffer->ring + read_pos;
len = strlen(head->text);

if (len) {
        /* Print out non-empty entry and proceed */
        fprintf(head->dest, "%s", head->text); // ==> SEGV
        read_pos += sizeof(*head) + len;
} else {
        /* Emptry entries mark the wrap-around */
        read_pos = 0;
}

Obviously the value of buffer->read_pos is not correct or the buffer
pointer returned by get_next_buffer() points to a wrong address.

Christoph

Am Donnerstag, den 27.08.2009, 10:24 +0200 schrieb Jan Kiszka:
> Christoph Permes wrote:
> > Am Mittwoch, den 26.08.2009, 10:12 +0200 schrieb Gilles Chanteperdrix:
> >> Christoph Permes wrote:
> >>> Hi, 
> >>>
> >>> I'm using rt_printf for debug output. When running tests for 20 hours or
> >>> longer, sometimes I get a segmentation fault.
> >>>
> >>> The backtrace shows:
> >>> #0  0xb7d008d8 in fputs () from /lib/libc.so.6
> >>> #1  0xb7f26f61 in print_buffers () from /usr/xenomai/lib/librtdk.so.0
> >>> #2  0xb7f26fb3 in printer_loop () from /usr/xenomai/lib/librtdk.so.0
> >>> #3  0xb7c92f3b in start_thread () from /lib/libpthread.so.0
> >>> #4  0xb7d6fb6e in clone () from /lib/libc.so.6
> >>>
> >>> It seems to me that there is a bug in the print thread.
> >>>
> >>> My program runs on x86 using the following software versions:
> >>> Kernel 2.6.29.5
> >>> Xenomai 2.4.9
> >>> I-Pipe patch: adeos-ipipe-2.6.29.5-x86-2.4-02.patch
> >> Could you try the following patch?
> >>
> >> diff --git a/src/rtdk/rt_print.c b/src/rtdk/rt_print.c
> >> index 0615247..a0aeec3 100644
> >> --- a/src/rtdk/rt_print.c
> >> +++ b/src/rtdk/rt_print.c
> >> @@ -422,6 +422,7 @@ void __rt_print_init(void)
> >>         pthread_attr_t thattr;
> >>         const char *value_str;
> >>         unsigned long long period;
> >> +       unsigned stksize;
> >>
> >>         first_buffer = NULL;
> >>         seq_no = 0;
> >> @@ -457,6 +458,9 @@ void __rt_print_init(void)
> >>         pthread_cond_init(&printer_wakeup, NULL);
> >>
> >>         pthread_attr_init(&thattr);
> >> -       pthread_attr_setstacksize(&thattr, PTHREAD_STACK_MIN);
> >> +       stksize = 32768;
> >> +       if (stksize < PTHREAD_STACK_MIN)
> >> +               stksize = PTHREAD_STACK_MIN;
> >> +       pthread_attr_setstacksize(&thattr, stksize);
> >>         pthread_create(&printer_thread, &thattr, printer_loop, NULL);
> >>  }
> >>
> > 
> > I have tried the patch but it crashed again with the same backtrace.
> 
> Could you try to find out, what memory access is precisely causing the
> SEGV? Maybe even what variables of the rt_printf code have invalid
> states? Or do you have a portable test case for us to reproduce the issue?
> 
> Thanks,
> Jan
>