All of lore.kernel.org
 help / color / mirror / Atom feed
* [Xenomai] Problem with MALLOC_CHECK_
@ 2012-09-07  5:26 Bill Vareka
  2012-09-07  5:55 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 4+ messages in thread
From: Bill Vareka @ 2012-09-07  5:26 UTC (permalink / raw)
  To: xenomai

   We've discovered a weird problem.  Basically, when using the xenomai 
posix skin and allocating and releasing large amounts of memory in a 
secondary mode thread, the application corrupts the entire system 
(kernel and all) *if* the MALLOC_CHECK_ macro is disabled.  Attached is 
a simple c++ demo program showing this problem (compile with gcc).  If 
you compile using standard posix it works no matter what.  If you 
compile using the xenomai posix skin, then if the environment variable 
MALLOC_CHECK_=3 then the program runs fine with no problems.  However, 
if you run with MALLOC_CHECK_=0 then the program appears to corrupt 
system memory.   After running this program, less, cat, and other 
standard programs now segfault and won't run.  Also in our case, we see 
that the output of ifconfig is also corrupted (shows table data rather 
than normal format).  The kernel is completely unstable.
We have encountered the problem before without identifying the source.  
Currently this affected us because our application ran fine under a 
login shell when testing (since it automatically defined the env var) 
but when we added a launch script to sysVinit to automatically launch it 
at startup, it failed because the environmental variables were much 
different there and did not define this variable.

Again, our app is C++ and this test is with stl strings but I strongly 
suspect the same behavior can be generated using a standard C program 
and malloc/free.

Our setup:

architecture x86 32-bit
Linux 2.6.38.8
adeos ipipe 2.11-01
xenomai-2.6.1
gcc46-4.6.2_20111026-1.1.4.i586
libstdc++46-4.6.2_20111026-1.1.4.i586
glibc-2.14.1-14.12.2.i686

Regards,
Bill Vareka
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: memtst.cpp
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20120907/ad3c81c5/attachment.ksh>

^ permalink raw reply	[flat|nested] 4+ messages in thread
* [Xenomai]  Problem with MALLOC_CHECK_
@ 2012-09-11 16:45 Jeff Weber
  2012-09-12 20:59 ` Gilles Chanteperdrix
  0 siblings, 1 reply; 4+ messages in thread
From: Jeff Weber @ 2012-09-11 16:45 UTC (permalink / raw)
  To: gilles.chanteperdrix; +Cc: bill, Xenomai Mailing List

Gilles:

On 09/07/2012 7 07:55:08 CEST 2012 Gilles Chanteperdrix wrote:

> On 09/07/2012 07:26 AM, Bill Vareka wrote:
>
> >    We've discovered a weird problem.  Basically, when using the xenomai
> > posix skin and allocating and releasing large amounts of memory in a
> > secondary mode thread, the application corrupts the entire system
> > (kernel and all) *if* the MALLOC_CHECK_ macro is disabled.  Attached is
> > a simple c++ demo program showing this problem (compile with gcc).  If
> > you compile using standard posix it works no matter what.  If you
> > compile using the xenomai posix skin, then if the environment variable
> > MALLOC_CHECK_=3 then the program runs fine with no problems.  However,
> > if you run with MALLOC_CHECK_=0 then the program appears to corrupt
> > system memory.   After running this program, less, cat, and other
> > standard programs now segfault and won't run.  Also in our case, we see
> > that the output of ifconfig is also corrupted (shows table data rather
> > than normal format).  The kernel is completely unstable.
> > We have encountered the problem before without identifying the source.
> > Currently this affected us because our application ran fine under a
> > login shell when testing (since it automatically defined the env var)
> > but when we added a launch script to sysVinit to automatically launch
it
> > at startup, it failed because the environmental variables were much
> > different there and did not define this variable.
> >
> > Again, our app is C++ and this test is with stl strings but I strongly
> > suspect the same behavior can be generated using a standard C program
> > and malloc/free.
> >
> > Our setup:
> >
> > architecture x86 32-bit
> > Linux 2.6.38.8
> > adeos ipipe 2.11-01
>
>
> Could you check the I-pipe patch for Linux 3.2? It has this commit:
>
http://git.denx.de/?p=ipipe.git;a=commit;h=c9f834f80257c4e7c2c01a3c6d34f5485af2be51
>
> Which 2.6.38 does not appear to have.

I am working with Bill Vareka on this issue.  Switching to Linux 3.2.21,
Xenomai-2.6.1 and using the ipipe-core-3.2.21-x86-1.patch did not make any
difference.  Our application still requires MALLOC_CHECK_=3 for glibc.

We are using glibc-2.14.1-14.12.2 .

Jeff Weber

^ permalink raw reply	[flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-09-12 20:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-09-07  5:26 [Xenomai] Problem with MALLOC_CHECK_ Bill Vareka
2012-09-07  5:55 ` Gilles Chanteperdrix
  -- strict thread matches above, loose matches on Subject: below --
2012-09-11 16:45 Jeff Weber
2012-09-12 20:59 ` Gilles Chanteperdrix

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.