Bug 29766 - Mono Runtime crashes when used with valgrind with/without Embedded Runtime
Summary: Mono Runtime crashes when used with valgrind with/without Embedded Runtime
Status: NEEDINFO
Alias: None
Product: Runtime
Classification: Mono
Component: JIT (show other bugs)
Version: 3.12.0
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2015-05-05 15:06 UTC by Nathan Wesley
Modified: 2018-04-05 22:23 UTC (History)
6 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 29766 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEEDINFO

Description Nathan Wesley 2015-05-05 15:06:38 UTC
I'm having problem debugging my application for memory leaks. because of a segfault that keeps happening in Mono Runtime. 

this small code results in a segfault when i debug it with valgrind. please not that  it works normally without using it.

MonoDomain *domain = mono_jit_init("test");
mono_jit_cleanup(domain);


also trying the exact example provided here https://github.com/mono/mono/blob/master/samples/embed/test-invoke.c results in the same segfault

this problem is NOT ONLY with the embedded API if i try this with the original mono command

valgrind mono invoke.exe 


the same thing happens and this is the valgrind output

-----------------------------------------------------------------------------------------------
==5228== Command: mono invoke.exe
==5228== 
==5228== Invalid write of size 1
==5228==    at 0x505A59: ??? (in /usr/bin/mono-sgen)
==5228==    by 0x4AE6E0: ??? (in /usr/bin/mono-sgen)
==5228==    by 0x4B0512: ??? (in /usr/bin/mono-sgen)
==5228==    by 0x42AD62: ??? (in /usr/bin/mono-sgen)
==5228==    by 0x4822A1: mono_main (in /usr/bin/mono-sgen)
==5228==    by 0x5788EC4: (below main) (libc-start.c:287)
==5228==  Address 0x5 is not stack'd, malloc'd or (recently) free'd
==5228== 
==5228== 
==5228== Process terminating with default action of signal 11 (SIGSEGV)
==5228==  Access not within mapped region at address 0x5
==5228==    at 0x505A59: ??? (in /usr/bin/mono-sgen)
==5228==    by 0x4AE6E0: ??? (in /usr/bin/mono-sgen)
==5228==    by 0x4B0512: ??? (in /usr/bin/mono-sgen)
==5228==    by 0x42AD62: ??? (in /usr/bin/mono-sgen)
==5228==    by 0x4822A1: mono_main (in /usr/bin/mono-sgen)
==5228==    by 0x5788EC4: (below main) (libc-start.c:287)
==5228==  If you believe this happened as a result of a stack
==5228==  overflow in your program's main thread (unlikely but
==5228==  possible), you can try to increase the size of the
==5228==  main thread stack using the --main-stacksize= flag.
==5228==  The main thread stack size used in this run was 8388608.
==5228== 
==5228== HEAP SUMMARY:
==5228==     in use at exit: 3,020 bytes in 123 blocks
==5228==   total heap usage: 804 allocs, 681 frees, 27,598 bytes allocated
==5228== 
==5228== LEAK SUMMARY:
==5228==    definitely lost: 16 bytes in 1 blocks
==5228==    indirectly lost: 40 bytes in 3 blocks
==5228==      possibly lost: 0 bytes in 0 blocks
==5228==    still reachable: 2,964 bytes in 119 blocks
==5228==         suppressed: 0 bytes in 0 blocks
==5228== Rerun with --leak-check=full to see details of leaked memory
==5228== 
==5228== For counts of detected and suppressed errors, rerun with: -v
==5228== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)

-------------------------------------------------------------------------------------------------------------


i tried to use a suppress file, but the suppress file does not prevent a segmentation fault from happening. 

it's really important to keep valgrind working so applications especially the ones that Embeds mono runtime can be debugged for memory leaks.  


-- VERSION INFORMATION


Mono Runtime Version Info

-------------------------------------
Mono JIT compiler version 3.12.1

 	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          supported, not enabled.
	GC:            sgen

---------------------------------------

also tried the newest version

---------------------------------------

Mono JIT compiler version 4.0.1

	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          supported, not enabled.
	GC:            sgen

---------------------------------------

Operating system:  Ubuntu 14.04.1 LTS
Comment 1 Zoltan Varga 2015-05-06 04:02:24 UTC
This is probably more of a valgrind problem than a mono one.
Comment 2 Nathan Wesley 2015-05-06 16:35:21 UTC
i don't think so. as i recall earlier versions of mono ~1 didn't have this problem. also a lot of large applications depend on valgrind and it's pretty stable. there is almost no way to debug native applications for memory leaks without using it.

i'm building an application that uses Mono Runtime and everything just became a mess i can't really check for anything because of this error.
Comment 3 naive231 2016-09-30 13:56:31 UTC
I'm experienced this issue,too.
Comment 4 luke.horsley 2017-03-17 09:30:11 UTC
I also have this issue.
Comment 5 Ludovic Henry 2018-04-05 22:23:05 UTC
Hello, can you still reproduce with latest version of Mono? If so, could you please provide a reproduction case, or at least a native stacktrace of the SIGSEGV. Thank you