[Mono-list] Problem with sgen

Sat Nov 22 02:22:07 UTC 2014

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  -  

> Mono-list at .ximian

>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
> 
> _______________________________________________
> Mono-list maillist  -  

> Mono-list at .ximian

> 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.