But why there will be an invalid read/write right after that and crash the process?
I'm using a native library (libuv) that directly read and write into the memory of the pinned object, when run under valgrind, any r/w opration fails and cause an error. Below is the valgrind output : --27495-- memcheck GC: 1000 nodes, 1 survivors ( 0.1%) --27495-- memcheck GC: 1000 nodes, 1 survivors ( 0.1%) --27495-- memcheck GC: 1000 nodes, 2 survivors ( 0.2%) ==27495== Conditional jump or move depends on uninitialised value(s) ==27495== at 0x5C7D06: conservatively_pin_objects_from (sgen-gc.c:1476) ==27495== by 0x5C83EC: scan_thread_data (sgen-gc.c:4022) ==27495== by 0x5CEAF3: collect_nursery (sgen-gc.c:2566) ==27495== by 0x5CF6CD: sgen_perform_collection (sgen-gc.c:3445) ==27495== by 0x5E73B7: mono_gc_alloc_obj_nolock (sgen-alloc.c:288) ==27495== by 0x5E77BB: mono_gc_alloc_obj (sgen-alloc.c:465) ==27495== by 0x40C4E5E: ??? ==27495== by 0x419D171: ??? ==27495== by 0x40BCE32: ??? ==27495== by 0x41D807: mono_jit_runtime_invoke (mini.c:6473) ==27495== by 0x5A41FA: mono_runtime_invoke (object.c:2827) ==27495== by 0x5A7FD2: mono_runtime_exec_main (object.c:4062) ==27495== Uninitialised value was created by a stack allocation ==27495== at 0x57CCF0: start_wrapper (threads.c:647) ==27495== ==27495== Invalid read of size 1 ==27495== at 0x41A2774: ??? ==27495== by 0x9: ??? ==27495== by 0xE1670FF: ??? ==27495== by 0xFFFF: ??? ==27495== by 0xF06604E: uv__read (stream.c:957) ==27495== by 0xF06706B: uv__stream_io (stream.c:1121) ==27495== by 0xF06B8AA: uv__io_poll (linux-core.c:263) ==27495== by 0xF05F5AB: uv_run (core.c:317) ==27495== by 0x41946A1: ??? ==27495== by 0x40BCE32: ??? ==27495== by 0x41D807: mono_jit_runtime_invoke (mini.c:6473) ==27495== by 0x5A41FA: mono_runtime_invoke (object.c:2827) ==27495== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==27495== ==27495== Thread 1 return signal frame corrupted. Killing process. ==27495== ==27495== Process terminating with default action of signal 11 (SIGSEGV) ==27495== General Protection Fault ==27495== at 0x54CE717: ??? (in /lib64/libpthread-2.12.so) ==27495== by 0x54CE70F: ??? (in /lib64/libpthread-2.12.so) ==27495== by 0x4FC16F: ??? (exceptions-amd64.c:838) ==27495== by 0x41A2773: ??? --27495-- Discarding syms at 0xbd031f0-0xbd0b648 in /lib64/libnss_files-2.12.so due to munmap() ==27495== ==27495== HEAP SUMMARY: ==27495== in use at exit: 3,216,798 bytes in 25,274 blocks ==27495== total heap usage: 133,643 allocs, 108,369 frees, 75,932,995 bytes allocated The SIGSEGV not only happen in uv__read. Is this a mistake made by valgrind? And also the boehm seems to have the same problem with sgen. Rodrigo Kumpera wrote > That's a false positive. sgen conservatively scans the stack and this does > trip valgrind. > > On Fri, Nov 21, 2014 at 10:29 AM, terender < > terender@ > > wrote: > >> There is a memory problem with mono-sgen on linux. I'm using some pinned >> byte[] buffers in my project, and there's a randomly crash with signal >> SIGSEGV, it could happen anywhere at anytime. >> >> I guess there's some write oprations out of bound in memory, so I use >> valgrind to check the program. >> >> Then I found that a while after the program start within some alloc >> oprations, valgrind report a problem in sgen that is: >> >> ==6504== Thread 1: >> ==6504== Conditional jump or move depends on uninitialised value(s) >> ==6504== at 0x5C4D46: conservatively_pin_objects_from (sgen-gc.c:1200) >> ==6504== by 0x5C5322: scan_thread_data (sgen-gc.c:3778) >> ==6504== by 0x5CA7BA: collect_nursery (sgen-gc.c:2298) >> ==6504== by 0x5CB877: sgen_perform_collection (sgen-gc.c:3196) >> ==6504== by 0x5E8CCF: mono_gc_alloc_obj_nolock (sgen-alloc.c:315) >> ==6504== by 0x5E90E3: mono_gc_alloc_obj (sgen-alloc.c:491) >> ==6504== by 0x40C09E2: ??? >> ==6504== by 0x4198331: ??? >> ==6504== by 0x40BBF42: ??? >> ==6504== by 0x41DE33: mono_jit_runtime_invoke (mini.c:6738) >> ==6504== by 0x5A252A: mono_runtime_invoke (object.c:2831) >> ==6504== by 0x5A5DCF: mono_runtime_exec_main (object.c:4096) >> ==6504== Uninitialised value was created by a stack allocation >> ==6504== at 0x57D2E0: start_wrapper (threads.c:701) >> >> >> Any read or write oprations right after that would trigger an Invalid >> write/read error in valgrind and then process got killed. >> >> Is that a bug in sgen collect_nursery with pinned objects in nursery >> heap? >> >> I have checked on both mono 3.2.3 and 3.10.0, and I'm using tarball to >> compile them myself. >> The enviroment is CentOS 6.6 Kernal 2.6.32-358.6.2.el6.x86_64, GCC >> version >> 4.4.7 >> >> I could upload the whole log of valgrind for both mono 3.2.3 and 3.10.0 >> if >> needed. >> >> >> Btw: the problem does not happen if I use boehm >> >> >> >> >> -- >> View this message in context: >> http://mono.1490590.n4.nabble.com/Problem-with-sgen-tp4664753.html >> Sent from the Mono - General mailing list archive at Nabble.com. >> _______________________________________________ >> Mono-list maillist - > [email protected] >> http://lists.ximian.com/mailman/listinfo/mono-list >> > > _______________________________________________ > Mono-list maillist - > [email protected] > http://lists.ximian.com/mailman/listinfo/mono-list -- View this message in context: http://mono.1490590.n4.nabble.com/Problem-with-sgen-tp4664753p4664767.html Sent from the Mono - General mailing list archive at Nabble.com. _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
