* AW: [Xenomai-help] memset of heap crashes Xenomai-Task
@ 2006-07-11 6:25 Roderik_Wildenburg
2006-07-11 8:09 ` Wolfgang Grandegger
0 siblings, 1 reply; 6+ messages in thread
From: Roderik_Wildenburg @ 2006-07-11 6:25 UTC (permalink / raw)
To: gilles.chanteperdrix; +Cc: xenomai
>
> 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)
Thank you for your help
Roderik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AW: [Xenomai-help] memset of heap crashes Xenomai-Task
2006-07-11 6:25 AW: [Xenomai-help] memset of heap crashes Xenomai-Task Roderik_Wildenburg
@ 2006-07-11 8:09 ` Wolfgang Grandegger
2006-07-11 8:22 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Wolfgang Grandegger @ 2006-07-11 8:09 UTC (permalink / raw)
To: Roderik_Wildenburg; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
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.
Wolfgang.
[-- Attachment #2: xenomai-heap-access.patch --]
[-- Type: text/x-patch, Size: 582 bytes --]
+ diff -u xenomai/ksrc/nucleus/heap.c.OLD xenomai/ksrc/nucleus/heap.c
--- xenomai/ksrc/nucleus/heap.c.OLD 2006-06-30 10:29:34.000000000 +0200
+++ xenomai/ksrc/nucleus/heap.c 2006-07-11 09:46:30.000000000 +0200
@@ -1044,8 +1044,10 @@
vabase = (unsigned long)ptr;
- for (vaddr = vabase; vaddr < vabase + size; vaddr += PAGE_SIZE)
+ for (vaddr = vabase; vaddr < vabase + size; vaddr += PAGE_SIZE) {
SetPageReserved(virt_to_page(__va_to_kva(vaddr)));
+ *(int *)vaddr = 0; /* touch page once */
+ }
} else {
/*
* Otherwise, we have been asked for some kmalloc()
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: AW: [Xenomai-help] memset of heap crashes Xenomai-Task
2006-07-11 8:09 ` Wolfgang Grandegger
@ 2006-07-11 8:22 ` Jan Kiszka
2006-07-11 8:42 ` Wolfgang Grandegger
0 siblings, 1 reply; 6+ messages in thread
From: Jan Kiszka @ 2006-07-11 8:22 UTC (permalink / raw)
To: Wolfgang Grandegger; +Cc: Roderik_Wildenburg, xenomai
[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]
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.]
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AW: [Xenomai-help] memset of heap crashes Xenomai-Task
2006-07-11 8:22 ` Jan Kiszka
@ 2006-07-11 8:42 ` Wolfgang Grandegger
0 siblings, 0 replies; 6+ messages in thread
From: Wolfgang Grandegger @ 2006-07-11 8:42 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Roderik_Wildenburg, xenomai
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* AW: [Xenomai-help] memset of heap crashes Xenomai-Task
@ 2006-07-11 6:09 Roderik_Wildenburg
2006-07-11 6:22 ` Jan Kiszka
0 siblings, 1 reply; 6+ messages in thread
From: Roderik_Wildenburg @ 2006-07-11 6:09 UTC (permalink / raw)
To: jan.kiszka; +Cc: xenomai
>
> First of all, I'm not sure if that 8K of stack is enough on
> PPC with 2.4, on x86 over 2.6 it isn't. The native skin picks
> PTHREAD_STACK_MIN*4 for you by default. Is this too much?
> Unless dealing with dozens of
> *simple* threads, reducing this makes no sense to me.
?? Greping for PTHREAD_STACK_MIN xenomai/posix/pthread.h tells me,
it is 1024. 1024*4=4096. This is less than 8192 ;-)
Is there a differnce between x86 and PPC.
(I simply did not realize that there is a default value for
the stacksize. Therfore I choose my own value, which was based on my
vxWorks experince)
>
> Then there was this bug:
>
> @@ -168,13 +169,13 @@
> void root_thread_exit(void)
> {
> int i;
> - RT_HEAP_INFO *hpinfo;
> + RT_HEAP_INFO hpinfo;
>
> printf("UDP->root_thread_exit\n");
>
> for(i=0;i<MAXHEAPBLOCKS;i++)
> {
> - if( !rt_heap_inquire(&bigheap[i],hpinfo) )
> + if( !rt_heap_inquire(&bigheap[i],&hpinfo) )
> rt_heap_delete(&bigheap[i]);
> }
Thank you ! 4 eyes see more than 2.
(but this is probably not the reason for the segmentation fault, as
this routine is called for exit only !?)
But even after correcting this error, I get segmentation faults (not
with
the first start but with the second or third)
>
> Now I get some other strange effects (e.g. kernel oopses after OOM
> oopses) that need a closer look under qemu later.
Thanks a lot.
Roderik
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: AW: [Xenomai-help] memset of heap crashes Xenomai-Task
2006-07-11 6:09 Roderik_Wildenburg
@ 2006-07-11 6:22 ` Jan Kiszka
0 siblings, 0 replies; 6+ messages in thread
From: Jan Kiszka @ 2006-07-11 6:22 UTC (permalink / raw)
To: Roderik_Wildenburg; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 2129 bytes --]
Roderik_Wildenburg@domain.hid wrote:
>> First of all, I'm not sure if that 8K of stack is enough on
>> PPC with 2.4, on x86 over 2.6 it isn't. The native skin picks
>> PTHREAD_STACK_MIN*4 for you by default. Is this too much?
>> Unless dealing with dozens of
>> *simple* threads, reducing this makes no sense to me.
>
> ?? Greping for PTHREAD_STACK_MIN xenomai/posix/pthread.h tells me,
> it is 1024. 1024*4=4096. This is less than 8192 ;-)
That's for the kernel-space usage of the posix skin. In user-space you
have to look at /usr/include:
/usr/include/bits/local_lim.h:#define PTHREAD_STACK_MIN 16384
(glibc-2.4, x86 of course)
> Is there a differnce between x86 and PPC.
> (I simply did not realize that there is a default value for
> the stacksize. Therfore I choose my own value, which was based on my
> vxWorks experince)
Again, that /might/ be fine on PPC, cannot tell.
>
>
>> Then there was this bug:
>>
>> @@ -168,13 +169,13 @@
>> void root_thread_exit(void)
>> {
>> int i;
>> - RT_HEAP_INFO *hpinfo;
>> + RT_HEAP_INFO hpinfo;
>>
>> printf("UDP->root_thread_exit\n");
>>
>> for(i=0;i<MAXHEAPBLOCKS;i++)
>> {
>> - if( !rt_heap_inquire(&bigheap[i],hpinfo) )
>> + if( !rt_heap_inquire(&bigheap[i],&hpinfo) )
>> rt_heap_delete(&bigheap[i]);
>> }
>
> Thank you ! 4 eyes see more than 2.
> (but this is probably not the reason for the segmentation fault, as
> this routine is called for exit only !?)
True.
> But even after correcting this error, I get segmentation faults (not
> with
> the first start but with the second or third)
>
>
>> Now I get some other strange effects (e.g. kernel oopses after OOM
>> oopses) that need a closer look under qemu later.
>
I re-tried the setup, but was "only" able to find a 2.6-kernel bug in
the OOM roll-back path of vmalloc (2.4 is unaffected). The other issue,
totally failing rt_heap_alloc, was not reproducable. I must have messed
something up on the test box at work.
So this means I cannot trigger your problem here on x86/2.6, sorry.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2006-07-11 8:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-11 6:25 AW: [Xenomai-help] memset of heap crashes Xenomai-Task Roderik_Wildenburg
2006-07-11 8:09 ` Wolfgang Grandegger
2006-07-11 8:22 ` Jan Kiszka
2006-07-11 8:42 ` Wolfgang Grandegger
-- strict thread matches above, loose matches on Subject: below --
2006-07-11 6:09 Roderik_Wildenburg
2006-07-11 6:22 ` Jan Kiszka
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.