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 _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
