All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Peter Puchwein <peter.puchwein@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] rt_print segfault on program termination
Date: Thu, 08 Oct 2009 17:34:05 +0200	[thread overview]
Message-ID: <4ACE066D.6080404@domain.hid> (raw)
In-Reply-To: <4ACE02FF.1090709@domain.hid>

Peter Puchwein wrote:
> Gilles Chanteperdrix wrote:
>> Christoph Permes wrote:
>>> Hi,
>>>
>>> We use a vmware virtual machine for simulation and testing our realtime
>>> applications.
>>> Every time when a realtime application terminates the following core
>>> dump occures:
>>>
>>> Program terminated with signal 11, Segmentation fault.
>>> [New process 11728]
>>> [New process 11726]
>>> [New process 11727]
>>> #0  0xb7e3e675 in free () from /lib/libc.so.6
>>> (gdb) bt
>>> #0  0xb7e3e675 in free () from /lib/libc.so.6
>>> #1  0xb80551dd in cleanup_buffer (buffer=0x81dd210) at rt_print.c:350
>>> #2  0xb7dbee27 in __nptl_deallocate_tsd () from /lib/libpthread.so.0
>>> #3  0xb7dbff49 in start_thread () from /lib/libpthread.so.0
>>> #4  0xb7e9cb6e in clone () from /lib/libc.so.6
>>>
>>> The line where the segfault occures is
>>> free(buffer->ring);
>>>
>>> The segfault never happens when running on a real machine, so it's no
>>> problem when running in production, but it is annoying when every run in
>>> the test environment leads to a segmentation fault.
>>>
>>> Maybe it is a timing related issue as there are no problems on a real
>>> machine.
>> Did you found the issue that was causing segmentation faults, or did you
>> keep your workaround?
>>
> 
> We kept our workaround, because we need an rt_print without 
> mode-switching the realtime-task.
> With the mode-switching version we didn't get any errors, so we couldn't 
> find out more details about the error.
> But it seems that there is a time-bounded issue in rt_print, depending 
> on the speed of the system.

The error you had makes think that something corrupts the memory. So, by
corrupting memory you can get:
- segfaults in rt_printf
- segfaults in free
- segfaults in malloc

And probably many other effects. So, what you have done with your
workaround is to paper over the corruption issue, and then the programs
fails later. But I bet if you solve the first issue correctly, the
second will disappear. At least, we will no longer be able to think that
the first issue is the cause of the second.

-- 
                                          Gilles



  reply	other threads:[~2009-10-08 15:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-08 15:03 [Xenomai-help] rt_print segfault on program termination Christoph Permes
2009-10-08 15:07 ` Gilles Chanteperdrix
2009-10-08 15:19   ` Peter Puchwein
2009-10-08 15:34     ` Gilles Chanteperdrix [this message]
2009-10-16  8:03       ` Peter Puchwein

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=4ACE066D.6080404@domain.hid \
    --to=gilles.chanteperdrix@xenomai.org \
    --cc=peter.puchwein@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.