From: Christoph Permes <christoph.permes@domain.hid>
To: Jan Kiszka <jan.kiszka@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] Segmentation fault in rt_printf print thread
Date: Mon, 31 Aug 2009 10:09:56 +0200 [thread overview]
Message-ID: <1251706196.4308.32.camel@domain.hid> (raw)
In-Reply-To: <4A979E68.1040805@domain.hid>
Am Freitag, den 28.08.2009, 11:07 +0200 schrieb Jan Kiszka:
> Christoph Permes wrote:
>
> Untested stuff as I should already be on the road. Here is another try,
> but please don't expect replies from me over this weekend.
>
> Jan
>
> diff --git a/src/rtdk/rt_print.c b/src/rtdk/rt_print.c
> index 0615247..06dabc1 100644
> --- a/src/rtdk/rt_print.c
> +++ b/src/rtdk/rt_print.c
> @@ -16,6 +16,7 @@
> * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> */
>
> +#include <assert.h>
> #include <errno.h>
> #include <inttypes.h>
> #include <limits.h>
> @@ -37,7 +38,10 @@
>
> #define RT_PRINT_LINE_BREAK 256
>
> +#define RT_PRINT_HEAD_MAGIC 0xDEADBEAF
> +
> struct entry_head {
> + uint32_t magic;
> FILE *dest;
> uint32_t seq_no;
> char text[1];
> @@ -103,6 +107,10 @@ int rt_vfprintf(FILE *stream, const char *format, va_list args)
> read_pos = buffer->read_pos;
> xnarch_read_memory_barrier();
>
> + assert(write_pos == read_pos ||
> + ((struct entry_head *)buffer->ring + buffer->read_pos)->magic ==
> + RT_PRINT_HEAD_MAGIC);
> +
> /* Is our write limit the end of the ring buffer? */
> if (write_pos >= read_pos) {
> /* Keep a savety margin to the end for at least an empty entry */
> @@ -114,6 +122,7 @@ int rt_vfprintf(FILE *stream, const char *format, va_list args)
> if (len == 0 && read_pos > sizeof(struct entry_head)) {
> /* Write out empty entry */
> head = buffer->ring + write_pos;
> + head->magic = RT_PRINT_HEAD_MAGIC;
> head->seq_no = seq_no;
> head->text[0] = 0;
>
> @@ -136,6 +145,10 @@ int rt_vfprintf(FILE *stream, const char *format, va_list args)
>
> res = vsnprintf(head->text, len, format, args);
>
> + assert(write_pos == read_pos ||
> + ((struct entry_head *)buffer->ring + buffer->read_pos)->magic ==
> + RT_PRINT_HEAD_MAGIC);
> +
> if (res < len) {
> /* Text was written completely, res contains its length */
> len = res;
> @@ -147,6 +160,7 @@ int rt_vfprintf(FILE *stream, const char *format, va_list args)
>
> /* If we were able to write some text, finalise the entry */
> if (len > 0) {
> + head->magic = RT_PRINT_HEAD_MAGIC;
> head->seq_no = ++seq_no;
> head->dest = stream;
>
> @@ -159,6 +173,7 @@ int rt_vfprintf(FILE *stream, const char *format, va_list args)
> read_pos <= write_pos && read_pos > buffer->size - write_pos) {
> /* An empty entry marks the wrap-around */
> head = buffer->ring + write_pos;
> + head->magic = RT_PRINT_HEAD_MAGIC;
> head->seq_no = seq_no;
> head->text[0] = 0;
>
> @@ -382,6 +397,8 @@ static void print_buffers(void)
> head = buffer->ring + read_pos;
> len = strlen(head->text);
>
> + assert(head->magic == RT_PRINT_HEAD_MAGIC);
> +
> if (len) {
> /* Print out non-empty entry and proceed */
> fprintf(head->dest, "%s", head->text);
>
I ran some tests over the weekend and got two more crashs. In both cases
the assert statement in print_buffers() failed.
After taking a closer look on the core file from last week and the new
ones I found out that parts of the printed text were overwritten with
one or more zero characters.
As a result the strlen() statement in print_buffers() does not return
the complete text length and the next try to read data from the buffer
fails as the read position is not correct anymore.
As a first workaround I will try to store the length returned by
vsnprintf() in the entry_head struct and use this value for incrementing
the read position to avoid the SEGV.
Christoph
next prev parent reply other threads:[~2009-08-31 8:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-26 8:01 [Xenomai-help] Segmentation fault in rt_printf print thread Christoph Permes
2009-08-26 8:12 ` Gilles Chanteperdrix
2009-08-27 6:24 ` Christoph Permes
2009-08-27 8:24 ` Jan Kiszka
2009-08-27 12:00 ` Christoph Permes
2009-08-28 7:38 ` Jan Kiszka
2009-08-28 8:38 ` Christoph Permes
2009-08-28 9:07 ` Jan Kiszka
2009-08-31 8:09 ` Christoph Permes [this message]
2009-09-07 7:35 ` Christoph Permes
2009-09-07 8:43 ` Jan Kiszka
2009-09-07 8:58 ` Gilles Chanteperdrix
2009-09-07 9:17 ` Jan Kiszka
2009-09-09 11:42 ` Gilles Chanteperdrix
2009-09-09 11:58 ` Gilles Chanteperdrix
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=1251706196.4308.32.camel@domain.hid \
--to=christoph.permes@domain.hid \
--cc=jan.kiszka@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.