[Mono-list] Too many heap sections
Rodrigo Kumpera
kumpera at gmail.com
Sat Dec 11 10:30:22 EST 2010
This is a known limitation of Boehm. Try using sgen instead.
On Sat, Dec 11, 2010 at 10:17 AM, Yury Serdyuk <Yury at serdyuk.botik.ru>wrote:
> Hi !
>
> I have a machine with 32 Gb memory:
>
> ]$ cat /proc/meminfo
> MemTotal: 32941336 kB
> MemFree: 32738196 kB
> Buffers: 372 kB
> Cached: 34852 kB
> SwapCached: 140 kB
> Active: 21748 kB
> Inactive: 25392 kB
> HighTotal: 0 kB
> HighFree: 0 kB
> LowTotal: 32941336 kB
> LowFree: 32738196 kB
> SwapTotal: 2104472 kB
> SwapFree: 2102356 kB
> Dirty: 0 kB
> Writeback: 0 kB
> AnonPages: 11856 kB
> Mapped: 5056 kB
> Slab: 40972 kB
> PageTables: 1252 kB
> NFS_Unstable: 0 kB
> Bounce: 0 kB
> CommitLimit: 48222340 kB
> Committed_AS: 22912 kB
> VmallocTotal: 34359738367 kB
> VmallocUsed: 273932 kB
> VmallocChunk: 34359464395 kB
> HugePages_Total: 0
> HugePages_Free: 0
> HugePages_Rsvd: 0
> Hugepagesize: 2048 kB
>
> and I would like to allocate and fill a hashtable with 90 mln elements.
> My program is
> <>
>
> using System;
> using System.Collections;
>
> public class HashTest {
>
> public static void Main (String[] args ) {
>
> int N = Convert.ToInt32 ( args [ 0 ] );
> Console.WriteLine ( "N = " + N );
>
> Hashtable hash = new Hashtable ( N );
> int n = 1;
>
> for ( int i = 0; i < N; i++ ) {
> if ( i % 1000000 == 0 ) {
> long m = GC.GetTotalMemory(false);
> Console.WriteLine ( "i = " + i + " Total memory = " + m );
> GC.Collect();
> GC.WaitForPendingFinalizers();
> }
> hash.Add ( i, n );
> }
>
> }
>
> }
>
> But I got
>
> ]$ mono HashTest.exe 90000000
> N = 90000000
> i = 0 Total memory = 2400268288
> i = 1000000 Total memory = 2448453632
> i = 2000000 Total memory = 2496643072
> . . .
> i = 87000000 Total memory = 6592643072
> i = 88000000 Total memory = 6640832512
> Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
> Stacktrace:
>
> at (wrapper managed-to-native)
> object.__icall_wrapper_mono_object_new_specific (intptr) <0x00049>
> at (wrapper managed-to-native)
> object.__icall_wrapper_mono_object_new_specific (intptr) <0x00049>
> at (wrapper alloc) object.Alloc (intptr) <0x0006f>
> at HashTest.Main (string[]) <0x0026e>
> at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object
> (object,intptr,intptr,intptr) <0x0007b>
>
> Native stacktrace:
>
> mono [0x491a17]
> /lib64/libpthread.so.0 [0x2b8c6e821b00]
> /lib64/libc.so.6(gsignal+0x35) [0x2b8c6ea5d665]
> /lib64/libc.so.6(abort+0x110) [0x2b8c6ea5eae0]
> mono [0x5db470]
> mono [0x5d14e9]
> mono [0x5d192c]
> mono [0x5d1b19]
> mono [0x5d1cd4]
> mono [0x5d536e]
> mono [0x5d6520]
> mono [0x5e05b9]
> mono [0x556565]
> mono(mono_object_new_alloc_specific+0x65) [0x556675]
> mono(mono_object_new_specific+0x88) [0x556da8]
> [0x7efa54fa]
>
> Debug info from gdb:
>
> Using host libthread_db library "/lib64/libthread_db.so.1".
> [Thread debugging using libthread_db enabled]
> [New Thread 47882154975808 (LWP 9662)]
> [New Thread 1076734272 (LWP 9670)]
> [New Thread 46915117578560 (LWP 9669)]
> [New Thread 46914593286464 (LWP 9668)]
> [New Thread 46914068994368 (LWP 9667)]
> [New Thread 46913544702272 (LWP 9666)]
> [New Thread 46913020410176 (LWP 9665)]
> [New Thread 2130254144 (LWP 9664)]
> [New Thread 1605962048 (LWP 9663)]
> 0x00002b8c6e82091b in read () from /lib64/libpthread.so.0
> 9 Thread 1605962048 (LWP 9663) 0x00002b8c6e81e286 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 8 Thread 2130254144 (LWP 9664) 0x00002b8c6e81e286 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 7 Thread 46913020410176 (LWP 9665) 0x00002b8c6e81e286 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 6 Thread 46913544702272 (LWP 9666) 0x00002b8c6e81e286 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 5 Thread 46914068994368 (LWP 9667) 0x00002b8c6e81e286 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 4 Thread 46914593286464 (LWP 9668) 0x00002b8c6e81e286 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 3 Thread 46915117578560 (LWP 9669) 0x00002b8c6e81e286 in
> pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
> 2 Thread 1076734272 (LWP 9670) 0x00002b8c6e81fdcd in sem_wait () from
> /lib64/libpthread.so.0
> 1 Thread 47882154975808 (LWP 9662) 0x00002b8c6e82091b in read () from
> /lib64/libpthread.so.0
>
> Thread 9 (Thread 1605962048 (LWP 9663)):
> #0 0x00002b8c6e81e286 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1 0x00000000005e1c44 in GC_wait_marker () at pthread_support.c:1788
> #2 0x00000000005d878e in GC_help_marker (my_mark_no=92) at mark.c:1116
> #3 0x00000000005e08d9 in GC_mark_thread (id=0x0) at pthread_support.c:548
> #4 0x00002b8c6e819fb7 in start_thread () from /lib64/libpthread.so.0
> #5 0x00002b8c6eaea78d in clone () from /lib64/libc.so.6
> . . .
>
> Thread 1 (Thread 47882154975808 (LWP 9662)):
> #0 0x00002b8c6e82091b in read () from /lib64/libpthread.so.0
> #1 0x0000000000491b1b in mono_handle_native_sigsegv (signal=<value
> optimized out>, ctx=<value optimized out>)
> at /usr/include/bits/unistd.h:35
> #2 <signal handler called>
> #3 0x00002b8c6ea5d665 in raise () from /lib64/libc.so.6
> #4 0x00002b8c6ea5eae0 in abort () from /lib64/libc.so.6
> #5 0x00000000005db470 in GC_abort (msg=0x6a1700 "Too many heap sections:
> Increase MAXHINCR or MAX_HEAP_SECTS")
> at misc.c:1099
> #6 0x00000000005d14e9 in GC_add_to_heap (p=0x2aacdb64f000, bytes=8388608)
> at alloc.c:840
> #7 0x00000000005d192c in GC_expand_hp_inner (n=2048) at alloc.c:994
> #8 0x00000000005d1b19 in GC_collect_or_expand (needed_blocks=1,
> ignore_off_page=0) at alloc.c:1070
> #9 0x00000000005d1cd4 in GC_allocobj (sz=3, kind=0) at alloc.c:1125
> #10 0x00000000005d536e in GC_generic_malloc_inner (lb=24, k=0) at
> malloc.c:136
> #11 0x00000000005d6520 in GC_generic_malloc_many (lb=24, k=0,
> result=0x8e1eb8) at mallocx.c:513
> #12 0x00000000005e05b9 in GC_local_malloc_atomic (bytes=20) at
> pthread_support.c:391
> #13 0x0000000000556565 in mono_object_new_ptrfree (vtable=0x1d9a8318) at
> object.c:4232
> #14 0x0000000000556675 in mono_object_new_alloc_specific
> (vtable=0x1d9a8318) at object.c:4205
> #15 0x0000000000556da8 in mono_object_new_specific (vtable=0x1d9a8318) at
> object.c:4196
> #16 0x000000007efa54fa in ?? ()
> #17 0x000000001d962e90 in ?? ()
> #18 0x0000000000000000 in ?? ()
> #0 0x00002b8c6e82091b in read () from /lib64/libpthread.so.0
>
> =================================================================
> Got a SIGABRT while executing native code. This usually indicates
> a fatal error in the mono runtime or one of the native libraries
> used by your application.
> =================================================================
>
> Aborted
>
> Any suggestions, please ?
> Mono version:
>
> mono -V
> Mono JIT compiler version 2.8.1 (tarball Thu Dec 2 14:44:51 MSK 2010)
> Copyright (C) 2002-2010 Novell, Inc and Contributors. www.mono-project.com
> TLS: __thread
> SIGSEGV: altstack
> Notifications: epoll
> Architecture: amd64
> Disabled: none
> Misc: debugger softdebug
> LLVM: supported, not enabled.
> GC: Included Boehm (with typed GC and Parallel Mark)
>
> Linux kernel :
>
> Linux node 2.6.18-rhel-alt13.M41.3 #1 SMP Tue Feb 2 12:09:59 MSK 2010
> x86_64 GNU/Linux
>
> Regards,
> Yury.
>
>
> _______________________________________________
> Mono-list maillist - Mono-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-list/attachments/20101211/c90176f1/attachment.html
More information about the Mono-list
mailing list