[Mono-list] Problem with sgen

terender terender at hotmail.com
Fri Nov 21 15:29:48 UTC 2014

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

I could upload the whole log of valgrind for both mono 3.2.3 and 3.10.0 if

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.

More information about the Mono-list mailing list