First coredump with "gc" (you really need a name for it)
Closed this issue · 11 comments
Jun 04 20:13:55 nexploit[11278]: Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS
Jun 04 20:13:56 nexploit[11278]: /usr/bin/nexploit: line 3: 11279 Aborted (core dumped) ./nexploit
Maybe we need to add to the README.md how to configure those and that it might be needed.
Thats a message from the old bdwgc...
Your executable hasn't been compiled with the new gc. If you run ldd on your executable you'll probably find its linked to libgc.
Nope, no libgc shown, followed all instructions.
I do see libgcc but I guess its not the same
linux-vdso.so.1 => (0x00007ffc8c7b0000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f875bb81000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f875b967000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f875b6fe000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f875b2ba000)
libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f875b06e000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f875acb3000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f875aa43000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f875a73a000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f875a51d000)
libevent-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 (0x00007f875a2d7000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f875a0cf000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8759ecb000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8759cb5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f87598eb000)
/lib64/ld-linux-x86-64.so.2 (0x00007f875be01000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f875bf92000)
libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f8759557000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f8759335000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f8759113000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f8758e32000)
libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f875737b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f8756ff9000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f8756de5000)
@ysbaddaden any idea what is going on?
I don't see the libgc in ldd but apparently I get messages related to it being used
I use this in the build script
shards update
cd lib/immix && make -B CUSTOM=-DNDEBUG
cd ../../
crystal build -s -p --release --no-debug src/nexploit.cr -o nexploit -Dgc_none
You probably have bdwgc linked statically. A nm -a nexploit | grep GC_ should print around 580 symbols with BDW where this GC (let's say Y) exposes less than 40.
I'm not sure what's happening... unless you're Crystal version doesn't support the gc_none flag, which was introduced in Crystal 0.24.1?
nm -a nexploit | grep GC_
000000000035a8b0 b ARGC_UNSAFE
0000000000113f00 T GC_add_roots
0000000000057ba0 T GC_collect
0000000000113ed0 T GC_collect_once
000000000035b218 b GC_collector
0000000000115440 T GC_Collector_addRoots
0000000000115860 T GC_Collector_collect
00000000001153a0 T GC_Collector_init
0000000000115460 T GC_Collector_mark
0000000000113cb0 T GC_deinit
0000000000113da0 T GC_free
0000000000114030 T GC_get_heap_usage
0000000000114020 T GC_get_memory_use
000000000035b228 b GC_global_allocator
0000000000114970 T GC_GlobalAllocator_allocateLarge
0000000000006200 t GC_GlobalAllocator_allocateLarge.cold.18
0000000000114e10 T GC_GlobalAllocator_deallocateLarge
00000000001140c0 T GC_GlobalAllocator_init
0000000000114490 T GC_GlobalAllocator_nextBlock
0000000000114680 T GC_GlobalAllocator_nextFreeBlock
0000000000114e40 T GC_GlobalAllocator_recycleBlocks
0000000000115c10 T GC_Hash_create
0000000000115ea0 T GC_Hash_delete
0000000000115fa0 T GC_Hash_deleteIf
0000000000116050 T GC_Hash_free
0000000000115d00 T GC_Hash_insert
0000000000115c40 T GC_Hash_search
0000000000113d00 T GC_in_heap
0000000000113a90 T GC_init
0000000000113fc0 T GC_large_heap_stats
000000000035b220 b GC_local_allocator
00000000001150e0 T GC_LocalAllocator_allocateSmall
0000000000115020 T GC_LocalAllocator_reset
0000000000113d40 T GC_malloc
0000000000113d70 T GC_malloc_atomic
0000000000113dd0 T GC_realloc
0000000000113ef0 T GC_register_collect_callback
0000000000113eb0 T GC_register_finalizer
0000000000113f20 T GC_small_heap_stats
No 580 symbols :) so it's your GC 100%
Also Crystal version:
Do you reproduce the BDW warning and the initial segfault? (hopefully with a gdb backtrace, immix.a is built with debug information).
@ysbaddaden for performance reasons I compile with DNDEBUG, I'm running a test now, will report any outcome here (hopefully it was an autobuild issue for a single instance)