More on the svn 23660 breakage.

[Rob Landley]

On Sunday 26 October 2008 18:21:09 Rob Landley wrote:
> On Sunday 26 October 2008 16:39:13 Rob Landley wrote:
> > So svn 23660 broke arm with my .config, but if I change my .config from
> > MALLOC=y to MALLOC_STANDARD=y it works again.
> >
> > Does anybody understand the difference between the "MALLOC"
> > and "MALLOC_SIMPLE" options?  The make help is not being useful here.
> >
> > Off to try MALLOC_SIMPLE...
>
> That works too.  It's only the base "MALLOC" option that doesn't work.
>
> I'm not sure if this is an oabi issue or if you just haven't been trying
> MALLOC=y.  (Still don't know the difference between MALLOC and
> MALLOC_SIMPLE, other than "one works".)

Ok, I spoke too soon.

MALLOC_SIMPLE allocates memory just fine.  As for _freeing_ that memory...

> checking for pid_t... yes
> sh invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=0
> [<c0020948>] (dump_stack+0x0/0x14) from [<c0050ea8>]
> (oom_kill_process+0x58/0x1a4) [<c0050e50>] (oom_kill_process+0x0/0x1a4)
> from [<c00513dc>] (out_of_memory+0x198/0x1e8) [<c0051244>]
> (out_of_memory+0x0/0x1e8) from [<c00535d8>] (__alloc_pages+0x270/0x2f4)
> [<c0053368>] (__alloc_pages+0x0/0x2f4) from [<c00555b8>]
> (__do_page_cache_readahead+0xcc/0x220) [<c00554ec>]
> (__do_page_cache_readahead+0x0/0x220) from [<c0055b6c>]
> (do_page_cache_readahead+0x6c/0x78) [<c0055b00>]
> (do_page_cache_readahead+0x0/0x78) from [<c00502e0>]
> (filemap_fault+0x178/0x3a8) r7:c7d11d80 r6:00000000 r5:00000000 r4:00000fff
> [<c0050168>] (filemap_fault+0x0/0x3a8) from [<c005ada8>]
> (__do_fault+0x74/0x408) [<c005ad34>] (__do_fault+0x0/0x408) from
> [<c005bd18>] (handle_mm_fault+0x2cc/0x5e8) [<c005ba4c>]
> (handle_mm_fault+0x0/0x5e8) from [<c0021f20>] (do_page_fault+0xf4/0x230)
> [<c0021e2c>] (do_page_fault+0x0/0x230) from [<c0022110>]
> (do_translation_fault+0x20/0x80) [<c00220f0>]
> (do_translation_fault+0x0/0x80) from [<c001c1ac>]
> (do_PrefetchAbort+0x18/0x1c) r5:00000008 r4:ffffffff
> [<c001c194>] (do_PrefetchAbort+0x0/0x1c) from [<c001c900>]
> (ret_from_exception+0x0/0x10) Exception stack(0xc163dfb0 to 0xc163dff8)
> dfa0:                                     43e57004 0000000c 43e57000
> 00000022 dfc0: 00000000 00000008 00000000 43e55004 00000000 bedbb52c
> bedbafe4 bedbb6e4 dfe0: 00000000 bedbaea8 40055dc0 0003ecf8 00000010
> ffffffff
> Mem-info:
> DMA per-cpu:
> CPU    0: hi:   42, btch:   7 usd:  40
> Active:31028 inactive:12 dirty:0 writeback:0 unstable:0
>  free:359 slab:378 mapped:0 pagetables:80 bounce:0
> DMA free:1436kB min:1440kB low:1800kB high:2160kB active:124112kB
> inactive:48kB present:130048kB pages_scanned:205550 all_unreclaimable? yes
> lowmem_reserve[]: 0 0 0
> DMA: 7*4kB 0*8kB 2*16kB 1*32kB 1*64kB 0*128kB 1*256kB 0*512kB 1*1024kB
> 0*2048kB 0*4096kB = 1436kB 12 total pagecache pages
> Swap cache: add 0, delete 0, find 0/0
> Free swap  = 0kB
> Total swap = 0kB
> Free swap:            0kB
> 32768 pages of RAM
> 429 free pages
> 771 reserved pages
> 326 slab pages
> 12 pages shared
> 0 pages swap cached
> Out of memory: kill process 1027 (make) score 916 or a child
> Killed process 1028 (sh)
> make: *** [configure-libiberty] Killed
> # checking for library containing strerror...
> /home/binutils-2.17/libiberty/configure: fork: Cannot allocate memory
> /home/binutils-2.17/libiberty/configure: fork: Cannot allocate memory
> /home/binutils-2.17/libiberty/configure: fork: Cannot allocate memory
> /home/binutils-2.17/libiberty/configure: fork: Cannot allocate memory

Yeah.  Not so much.

I guess I'll give MALLOC_STANDARD a try, and if that doesn't work go back to 
forcibly reverting the patch from my builds...

Rob