2008-05-23 03:49:55     Memory Allocation Failure

Document created by Aaronwu Employee on Aug 6, 2013
Version 1Show Document
  • View in full screen mode

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

Attachments

    Outcomes