Re: [Xenomai] Problem with MALLOC_CHECK_

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 09/11/2012 06:45 PM, Jeff Weber wrote:

> 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 .


I am unable to reproduce this issue, however, you could try:
- returning 0 at the very beginning of __ipipe_disable_ondemand_mapping
- returning 0 at the very beginning of __ipipe_pin_vma
- comment out the code between #ifdef CONFIG_IPIPE in mprotect

These would be the usual suspects which could explain what you see.

-- 
                                                                Gilles.