Re: [Xenomai] Memory paging trouble

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

On 07/16/2014 01:23 PM, Paal Tamas wrote:
> Dear All, I am using Xeno 2.6.3 together with a 3.0.15 Linux kernel
> on an i.MX6 ARM hardware. I am using the Posix skin.I have a memory
> paging problem inmy user mode app. I don't get any error message,
> only the contents of my memory buffer gets messed up. I try to
> describe what I see and what I suspect in as less words as possible:
> I allocate (using malloc) a buffer which is  more then 3 memory pages
> long (a page is 4096bytes in my case). I write a few bytes to the
> beginning, then a few bytes to the end, save the contents ina file.
> After that I fill the rest of the buffer from the beginning till the
> end and save the contents again into a file. I write unsigned int
> values into it starting with zero counting up to 3999.After this
> procedure the buffer should look like this (I indicate the memory
> page boundaries according to my test app):
> Page1.0.833Page2834.1857Page31858.2881Page42882.3905Page53906.3999
> But the content of the buffer looks like this:
> Page1.0.833Page22882.3905Page3288 2.3905Page42882.3905Page53906.3999
> It seems that the second and third pages, which were not added to the
> virtual memory of the process in the first cycle (because I wrote
> data only into the address ranges of the first and  fourth pages
> then) are 'missing", and the content of the fourth page show up
> on the address range of the second and third page. I see this strange
> behaviour only if I allocate this buffer in a Xenomai thread. If I do
> the allocation in the main thread of the process (e.g. in the main()
> function) the memory will not be corrupt!If I compile the same source
> code to native Linux and running on the same hardware, on the same
> kernel, it works fine, no memory corruption can be seen this time
> either. I found the following workarounds:WA1.: Initialize the buffer
> from the beginning to the end in a linear fashion after allocation
> (e.g. writing the bytes one after the other, ensure to add the memory
> pages one afte the other to the process).WA2.: Use calloc() instead
> of mal loc() which is the same workaround as WA1 wa! s. I am
> struggling with this issue since a week. Please help me where to
> search for the problem. In Xenomai, in the Linux kernel or in the
> stdlib? One more strange thing that I am not sure if it has anything
> to do with this issue. I do not get any runtime error if I DON'T
> call mlockall()! Why is that? I read somewhere that some libraries
> call mlockall() during initialization. Is it true? Thank you,Tamas 

Quite frankly, your mail is unreadable. Could you try and post a clear
and readable mail, preferably with a piece of code allowing to
reproduce the issue you meet?
-- 
                                                                Gilles.