2008-05-23 03:49:55 Memory Allocation Failure
kang p (INDIA)
Message: 56172
Hi all,
My Application crashes with following message.
--------------------------------------------------------------------------------
root:~> ./Test_App
Test_App: page allocation failure. order:8, mode:0x40d0
Hardware Trace:
0 Target : <0x003035c0> { _dump_stack + 0x0 }
Source : <0x0032ff6a> { ___alloc_pages + 0x17a }
1 Target : <0x0032ff6a> { ___alloc_pages + 0x17a }
Source : <0x0030b452> { _printk + 0x16 }
2 Target : <0x0030b44e> { _printk + 0x12 }
Source : <0x0030b2dc> { _vprintk + 0x1b0 }
3 Target : <0x0030b2d0> { _vprintk + 0x1a4 }
Source : <0xffa01132> { __common_int_entry + 0xd8 }
4 Target : <0xffa010d0> { __common_int_entry + 0x76 }
Source : <0xffa00ea8> { _return_from_int + 0x58 }
5 Target : <0xffa00ea8> { _return_from_int + 0x58 }
Source : <0xffa00e7e> { _return_from_int + 0x2e }
6 Target : <0xffa00e50> { _return_from_int + 0x0 }
Source : <0xffa010cc> { __common_int_entry + 0x72 }
7 Target : <0xffa010ca> { __common_int_entry + 0x70 }
Source : <0xffa0048a> { _asm_do_IRQ + 0x76 }
8 Target : <0xffa00482> { _asm_do_IRQ + 0x6e }
Source : <0x0030f362> { __local_bh_enable + 0x3e }
9 Target : <0x0030f324> { __local_bh_enable + 0x0 }
Source : <0x0030f5dc> { ___do_softirq + 0x94 }
10 Target : <0x0030f5d4> { ___do_softirq + 0x8c }
Source : <0x0030f5b4> { ___do_softirq + 0x6c }
11 Target : <0x0030f5a6> { ___do_softirq + 0x5e }
Source : <0x00312596> { _run_timer_softirq + 0x82 }
12 Target : <0x00312528> { _run_timer_softirq + 0x14 }
Source : <0x0031dc2c> { _hrtimer_run_queues + 0xe8 }
13 Target : <0x0031dc14> { _hrtimer_run_queues + 0xd0 }
Source : <0x0031dc34> { _hrtimer_run_queues + 0xf0 }
14 Target : <0x0031dc2e> { _hrtimer_run_queues + 0xea }
Source : <0x0031dc12> { _hrtimer_run_queues + 0xce }
15 Target : <0x0031dc02> { _hrtimer_run_queues + 0xbe }
Source : <0x0031dc56> { _hrtimer_run_queues + 0x112 }
Stack from 008cbdd8:
00000000 0032ff6e 00000000 00000001 000040d0 02ead9ac 00000008 000040d0
00000000 00000080 00000000 000240d0 00000000 008ca000 008ca000 008ca000
00000010 00000000 0066ad80 00330f7e 0045cc74 00000000 006fe920 00000020
000040d0 00000001 00000010 00000000 00000000 02ead820 000040d0 006fe920
00099fff 0033122e 00099000 02cbe1a0 04000073 0000ffff 04000021 00000000
00000000 00acdf0c 0032e702 00099000 0032eafa 00000000 008d25cc ffa02772
Call Trace:
[<00302d40>] _sys_mmap2+0x48/0x80
[<00302cf8>] _sys_mmap2+0x0/0x80
Mem-info:
DMA per-cpu:
CPU 0: Hot: hi: 6, btch: 1 usd: 5 Cold: hi: 2, btch: 1 usd: 1
Active:790 inactive:1106 dirty:0 writeback:0 unstable:0 free:427 slab:7865 mapped:0 pagetables:0
DMA free:1708kB min:872kB low:1088kB high:1308kB active:3160kB inactive:4424kB present:47752kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
DMA: 13*4kB 7*8kB 10*16kB 3*32kB 1*64kB 0*128kB 1*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 1708kB
12032 pages of RAM
461 free pages
1772 reserved pages
1554 pages shared
0 pages swap cached
Allocation of length 626688 from process 96 failed
DMA per-cpu:
CPU 0: Hot: hi: 6, btch: 1 usd: 5 Cold: hi: 2, btch: 1 usd: 1
Active:790 inactive:1106 dirty:0 writeback:0 unstable:0 free:427 slab:7865 mapped:0 pagetables:0
DMA free:1708kB min:872kB low:1088kB high:1308kB active:3160kB inactive:4424kB present:47752kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
DMA: 13*4kB 7*8kB 10*16kB 3*32kB 1*64kB 0*128kB 1*256kB 2*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB 0*32768kB = 1708kB
--------------------------------------------------------------------------------
Very Recently I'm stuck up with this problem.
I'm using BF533 - custom board ,latest uClinux distrubution 2008.
My RAM FS size is 16MB.
root:~> df -h
Filesystem Size Used Available Use% Mounted on
/dev/mtdblock0 14.0M 12.5M 678.0k 95% /
Whether this low memory leads to crash ?
Any one suggest me solution to resolve.
Thanks in Advance.
QuoteReplyEditDelete
2008-05-23 04:02:34 Re: Memory Allocation Failure
Mike Frysinger (UNITED STATES)
Message: 56173
with so little memory, things are obviously going to crash if you try to do any allocations that exceed the amount of free memory ... you need to either alleviate the memory pressure by moving things out of RAM or installing more RAM, or dont allocate any RAM in your application
if your filesystem is RAM backed, the first thing you should do is move it to flash. see the documentation for more information:
http://docs.blackfin.uclinux.org/doku.php?id=enabling_jffs2
QuoteReplyEditDelete
2008-05-23 05:38:36 Re: Memory Allocation Failure
kang p (INDIA)
Message: 56202 < div="">
Thanks very much mike.
root:~> cat /proc/meminfo
MemTotal: 41032 kB
MemFree: 29016 kB
Buffers: 228 kB
Cached: 8908 kB
SwapCached: 0 kB
Active: 716 kB
Inactive: 8420 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 20 kB
Writeback: 0 kB
AnonPages: 0 kB
Mapped: 0 kB
Slab: 2716 kB
SReclaimable: 812 kB
SUnreclaim: 1904 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
CommitLimit: 20516 kB
Committed_AS: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
It seems that i've free memory of 29MB in SDRAM,but i dont why it crashes?
Does any malloc,stack memory is allocated in applicatoin thread uses the RAM ?
I'm confused about this,can you please clarify this ?
<>
QuoteReplyEditDelete
2008-05-23 06:08:46 Re: Memory Allocation Failure
Mike Frysinger (UNITED STATES)
Message: 56203
sorry, i thought in your original post you said your system only had 16megs of SDRAM. you're hitting fragmentation problems as the crash dump you posted indicates. do not allocate and then free large chunks of memory in your application ... allocate them once and do not let them go, just pass it around internally.
QuoteReplyEditDelete
2008-05-23 07:35:03 Re: Memory Allocation Failure
kang p (INDIA)
Message: 56205 < div="">
thanks again mike.
It means that,it will result in problem during allocation and free of the larger chunks.Is it Right ?
You find my Custom boards memory layout in uClinux.
Board Memory: 64MB
Kernel Managed Memory: 64MB
Memory map:
text = 0x00300000-0x0041135c
init = 0x00412000-0x00420878
data = 0x00426350-0x0045d538
stack = 0x00428000-0x0042a000
bss = 0x0045d540-0x0066b320
available = 0x0066b320-0x02f00000
rootfs = 0x02f00000-0x03f00000
DMA Zone = 0x03f00000-0x04000000
I found that all memory allocated in the user space is between the range of the " available = 0x0066b320-0x02f00000 ".
If this is correct, how to find out the heap,stack used by my appication ?
Also please guide me with some docs ,where it explains clear about the memory sections maintained in the user and kernel space in uClinux.
<>
QuoteReplyEditDelete
2008-05-23 07:50:13 Re: Memory Allocation Failure
Mike Frysinger (UNITED STATES)
Message: 56207
there is no such thing as a heap with a no-mmu system. the entire memory space is technically the shared kernel and user space heap.
the same goes for stack. a chunk of memory is allocated at process init and setup as the stack which cannot grow.
all our docs are at http://docs.blackfin.uclinux.org/
QuoteReplyEditDelete
2008-05-23 09:51:33 Re: Memory Allocation Failure
Graham Davies (UNITED STATES)
Message: 56212
Mike wrote "there is no such thing as a heap with a no-mmu system ... the same goes for stack". This is the most bizarre thing I've read on this forum. Do we have a terminology problem here? The term "heap" is frequently used for what is strictly the "free store", i.e. the unused memory made available to a process for dynamic allocation via the malloc() and free() family of functions. Only the very smallest embedded systems lack a free store. I don't know how to begin debating "there is no such thing as a ... stack ...".
I am having problems with inexplicable behavior that comes and goes with unrelated software changes and is grossly affected by the amount of kernel memory allocated in our custom drivers. I am now wondering if there is something fundamentally different and unusual in how the Blackfin and/or uClinux implement "standard" features of embedded systems platforms. Can you say a few words on this, Mike?
Graham.
QuoteReplyEditDelete
2008-05-23 10:59:29 Re: Memory Allocation Failure
Robin Getz (UNITED STATES)
Message: 56216
Graham:
Although I'm not sure - I think Mike meant:
there is no such things as an application heap, when not using virtual memory. Application heap uses the kernel heap (any free memory in the system) - if application A steals all the memory in the system, application's B malloc will fail. (This normally doesn't happen on a virutal memory system which is backed by swap space, since A's memory can be swapped out, and there will always make room for B's heap).
"the same goes for stack", meaning the stack can not grow dyanamically. It needs to be determined and runs with a fixed size at compile time. If the stack exceeds it's bounds, applicaitons typically crash. (Which is why we added stack checking).
https://docs.blackfin.uclinux.org/doku.php?id=debuging_applications
https://docs.blackfin.uclinux.org/doku.php?id=operating_systems#introduction_to_uclinux
-Robin
QuoteReplyEditDelete
2008-05-23 11:15:14 Re: Memory Allocation Failure
Graham Davies (UNITED STATES)
Message: 56218
Robin, that makes sense. I guess Mike was a bit hurried.
What you're saying is that the kernel and all applications use the same free store. Note that this isn't necessarily so just because there is no MMU. The lack of virtual memory does not preclude the kernel and each application from having its own free store. With an MPU, you can even make sure than applications don't access each other's and the kernel's memory. But, I guess you're saying that uClinux on the Blackfin provides only one system-wide free store and everyone shares it. OK.
It's also clear, then, that each thread has its own stack. As you say, the lack of an MMU prevents more space being scrounged up for a stack as it grows, so stack size is fixed (probably at link time).
I will look at the references you provide and adjust my thinking to the news that the kernel and applications share a single free store. This is not what I expected, but my fault for not doing the research.
Graham.
QuoteReplyEditDelete
2008-05-23 13:51:37 Re: Memory Allocation Failure
Robin Getz (UNITED STATES)
Message: 56221
Graham:
Using the same free store for application/kernel heap isn't really a function of MMU/noMMU, (and really should not be thought of as a bad noMMU thing). it is a function of not normally having a device to swap to like most embedded targets. (things are a little more constrained on noMMU - since even if you did have a swap device, you can not support it without virtual memory support).
-Robin
QuoteReplyEditDelete
2008-05-23 14:41:21 Re: Memory Allocation Failure
Graham Davies (UNITED STATES)
Message: 56222
Well, Robin, I don't really agree with any of that, ...
Partitioning of free stores is not contingent on memory management.
Memory management is not contingent on the ability to swap to backing store.
... but I think I'm dragging the thread away from uClinux and Blackfin issues. For whatever reason, uClinux / Blackfin has a single free store for kernel and applications and I need to live with it. I agree it's not necessarily bad. It saves me from having to allocate my memory between mulitple free stores. But it can be bad, as it's no longer possible to configure an MPU to prevent an application from corrupting an area of free store in use by the kernel.
Graham.
QuoteReplyEditDelete
2008-05-23 15:41:40 Re: Memory Allocation Failure
Mike Frysinger (UNITED STATES)
Message: 56225
it isnt a Blackfin thing ... all ports that lack a MMU will behave this way
Robin communicated pretty much what i meant ... you cannot look at the memory range and say "this small chunk represents the heap for application XXX" because there is no such thing. when an application does allocations, it's going to come from all over, not from just one chunk of memory which has been dubbed the application's "heap".
this is generally unlike a MMU system where the heap and stack tend to be defined regions and when you do an allocation, it always comes from the same range. when it fills up, the MMU simply grows it.
QuoteReplyEditDelete
2008-05-23 17:04:20 Re: Memory Allocation Failure
Graham Davies (UNITED STATES)
Message: 56228
OK, understood. Everyone's in the same heap, so allocations are interleaved in unpredictable ways and we need to be aware of this and act accordingly. I didn't mean to imply that the Blackfin port was different from other uClinux ports; the fact is it's the only one I am even remotely familiary with, so I can't say anything about others.
Graham.
QuoteReplyEditDelete
2008-05-23 17:14:17 Re: Memory Allocation Failure
Mike Frysinger (UNITED STATES)
Message: 56230
right ... if you look at /proc/self/maps on a MMU system, you'll see a mapping with a [heap] label and this mapping is dynamic in size (all allocations come from it) ... there will be no such thing on a no-mmu system and instead, you'll see a whole lot more mappings from all over the physical memory map when an application starrts allocating a lot ... it wont be exactly 1-alloc-to-1-mapping as uClibc tries to handle smaller allocations better, but the difference should be quite noticeable