Re: AW: [Xenomai-help] memset of heap crashes Xenomai-Task

[Wolfgang Grandegger <wg@domain.hid>]

Jan Kiszka wrote:
> Wolfgang Grandegger wrote:
>> Roderik_Wildenburg@domain.hid wrote:
>>>> memset should work with Xenomai heaps, I suspect your problem is
>>>> rather that the memory is not really allocated until you memset it,
>>>> which fails when no memory is available. In this case, calling memset
>>>> on memory allocated with malloc should segfault the same way when the
>>>> system memory is exhausted. IIRC, this behaviour is documented in
>>>> mlockall manual page.
>>>>
>>> Mr. Denk told me about this strange (for RTOSs) behaviour of the Linux
>>> kernel. Therefore I used the Xenomai heap mechanism, expecting
>>> allocated memory is allocated at once not some time later (why do I
>>> allocate memory otherwise : to be shure memory is available).
>>> Does Xenomai use the Linux allocation mechanism ??
>>>
>>>
>>>> Be careful with sysconf(_SC_AVPHYS_PAGES), it may include the swap
>>>> size, but when mlocking memory, your application can not use swap
>>>> pages, so, you should substract the size of swap, if any.
>>>> Also, what is the value of /proc/sys/vm/overcommit_memory on your
>>>> system ?
>>>>
>>> Our System does not have a swap device\space.
>>> /proc/sys/vm/overcommit_memory = 0
>>> (whatever this means)
>> I gave your program a try on my MPC5200 and got the following output
>> (after some corrections):
>>
>> bash-2.05b# ./heap2
>> Start Heap
>> root_thread_init :
>> timer startedt
>> display task created
>> root_thread_init beendet
>> Available Memory 56238080 (Pagesize 4096)
>> heap 0 of size 16000000 created
>> Heap 0 allocated size 16000000
>> heap 1 of size 16000000 created
>> Heap 1 allocated size 16000000
>> heap 2 of size 16000000 created
>> Heap 2 allocated size 16000000
>> __alloc_pages: 0-order allocation failed (gfp=0x1f2/0)
>> Available Memory after allocation 8933376
>> __alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
>> Heap 3 created with size 4218880
>> Heap 3 allocated size 4218880
>> Memory allocated in total : 52218880
>> Segmentation fault
>>
>> The are some long delays (approx. 40 secs) around __alloc_pages. Finally
>> it crashes in memset. With the attached xenomai patch, which touches the
>> reserved page once, memset works fine. Let's wait what Philippe says. I
>> remember that the "touch" was needed for RTAI shared memory as well.
> 
> What is the difference between touching the page in kernel space and in
> user space? Is there no risk that the kernel will oops then at some
> point? Do we get the same result when touching the heap pages in user
> space immediately after rt_help_alloc'ing them? Roderik's demo allocates
> first and then touches/memsets. [I have no problem with the patch, I'm
> just trying to understand the mechanism.]

Well, after some more tests I realized, that the problem still shows up 
==> forget the patch and sorry for the noise. It seems to be more 
complicated (sometimes it runs, sometimes I see other crashes, etc.).

Wolfgang.