Bug 3016 - sgen doesn't work on osx 64 bit
Summary: sgen doesn't work on osx 64 bit
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: GC ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2012-01-23 11:58 UTC by Jonathan Shore
Modified: 2012-04-22 22:59 UTC (History)
4 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 on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Jonathan Shore 2012-01-23 11:58:20 UTC
I was analyzing a performance difference between linux and OSX for a mono application.   It was suggested to try sgen instead of the beohm GC.  Running with sgen with or without llvm caused an immediate SEGV.

Note that this program runs fine with the Beohm collector

This with mono 2.10.8 on OSX (10.7.2).   See dump below:


karma:Tests jshore$ mono-sgen bin/Debug/Test.exe 
INFO  [2012-01-23 11:52:28.090]: connecting to tick db
INFO  [2012-01-23 11:52:28.446]: creating instrument and caching series
* Assertion at sgen-gc.c:2506, condition `mono_sgen_need_bridge_processing ()' not met

Stacktrace:

  at (wrapper managed-to-native) object.__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr) <0xffffffff>
  at (wrapper alloc) object.AllocVector (intptr,intptr) <0xffffffff>
  at System.Collections.Generic.Dictionary`2<string, com.gf.common.utils.Any>.InitArrays (int) <0x000cf>
  at System.Collections.Generic.Dictionary`2<string, com.gf.common.utils.Any>.Init (int,System.Collections.Generic.IEqualityComparer`1<string>) <0x0009b>
  at System.Collections.Generic.Dictionary`2<string, com.gf.common.utils.Any>..ctor (int,System.Collections.Generic.IEqualityComparer`1<string>) <0x00017>
  at com.gf.common.collections.Map`2<string, com.gf.common.utils.Any>..ctor (int,System.Collections.Generic.IEqualityComparer`1<string>) <0x0008b>
  at com.gf.common.xml.XmlReader..ctor (string,bool) <0x00077>
  at com.gf.common.xml.XmlReader..ctor (string) <0x00017>
  at com.gf.common.xml.XmlNode.get_Parser () <0x0003f>
  at com.gf.common.xml.XmlValue.GetValue () <0x0001b>
  at com.gf.common.xml.XmlValue.op_Implicit (com.gf.common.xml.XmlValue) <0x00013>
  at com.gf.fin.core.Calendar.Load (com.gf.common.xml.XmlNode) <0x001e3>
  at com.gf.fin.core.Calendar.Load (string) <0x000cf>
  at com.gf.fin.core.Calendar..cctor () <0x0010f>
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
  at com.gf.fin.instruments.InstrumentFXForwardDef.Load (com.gf.common.xml.XmlNode) <0x0049f>
  at com.gf.fin.instruments.InstrumentFXForwardDef.LoadAll (string) <0x000cf>
  at com.gf.fin.instruments.InstrumentFXForwardDef..cctor () <0x0002f>
  at (wrapper runtime-invoke) object.runtime_invoke_void (object,intptr,intptr,intptr) <0xffffffff>
  at com.gf.fin.instruments.InstrumentDef.Find (com.gf.mkt.ids.MktId) <0x00083>
  at com.gf.exchanges.simulator.config.InstrumentParameters..ctor (com.gf.mkt.ids.MktId,com.gf.exchanges.core.latency.ISimulatedLatency,com.gf.exchanges.core.commissions.ICommission) <0x00083>
  at com.gf.exchanges.simulator.instruments.SimulatedInstrumentHistorical..ctor (com.gf.mkt.ids.MktId,com.gf.exchanges.core.latency.ISimulatedLatency,com.gf.exchanges.core.commissions.ICommission,com.gf.data.core.IDataService,long,long,bool) <0x0002b>
  at Tests.Simulator.Evaluate () <0x0027f>
  at Tests.TestPerformance.Main (string[]) <0x00017>
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void_object (object,intptr,intptr,intptr) <0xffffffff>

Native stacktrace:

	0   mono-sgen                           0x00092c6c mono_handle_native_sigsegv + 284
	1   mono-sgen                           0x000dcebd sigabrt_signal_handler + 109
	2   libsystem_c.dylib                   0x9c7a559b _sigtramp + 43
	3   ???                                 0xffffffff 0x0 + 4294967295
	4   libsystem_c.dylib                   0x9c740bdd abort + 167
	5   mono-sgen                           0x00281ed3 monoeg_g_logv + 243
	6   mono-sgen                           0x00281f86 monoeg_assertion_message + 54
	7   mono-sgen                           0x001e6ab4 stw_bridge_process + 68
	8   mono-sgen                           0x001ee228 restart_world + 216
	9   mono-sgen                           0x001ea140 minor_collect_or_expand_inner + 288
	10  mono-sgen                           0x001eab32 mono_gc_alloc_obj_nolock + 1138
	11  mono-sgen                           0x001eb034 mono_gc_alloc_vector + 180
	12  ???                                 0x0048e9f8 0x0 + 4778488
	13  ???                                 0x004886f4 0x0 + 4753140
	14  ???                                 0x007d1158 0x0 + 8196440
	15  ???                                 0x007d103c 0x0 + 8196156
	16  ???                                 0x007e8248 0x0 + 8290888
	17  ???                                 0x007e81e4 0x0 + 8290788
	18  ???                                 0x007e7f88 0x0 + 8290184
	19  ???                                 0x007e7ef8 0x0 + 8290040
	20  ???                                 0x007e7e30 0x0 + 8289840
	21  ???                                 0x007eab8c 0x0 + 8301452
	22  ???                                 0x007eab5c 0x0 + 8301404
	23  ???                                 0x007fc3c4 0x0 + 8373188
	24  ???                                 0x007fbf80 0x0 + 8372096
	25  ???                                 0x007fb318 0x0 + 8368920
	26  ???                                 0x00487f89 0x0 + 4751241
	27  mono-sgen                           0x0000cff2 mono_jit_runtime_invoke + 722
	28  mono-sgen                           0x001a4c8a mono_runtime_invoke + 170
	29  mono-sgen                           0x0019e89a mono_runtime_class_init_full + 1946
	30  mono-sgen                           0x0000c8a8 mono_jit_compile_method_with_opt + 2504
	31  mono-sgen                           0x0000ccc9 mono_jit_compile_method + 41
	32  mono-sgen                           0x0019f433 mono_compile_method + 83
	33  mono-sgen                           0x000963fb common_call_trampoline + 1083
	34  mono-sgen                           0x000939cb mono_magic_trampoline + 59
	35  ???                                 0x0043b066 0x0 + 4436070
	36  ???                                 0x007f75d0 0x0 + 8353232
	37  ???                                 0x007f74a8 0x0 + 8352936
	38  ???                                 0x00487f89 0x0 + 4751241
	39  mono-sgen                           0x0000cff2 mono_jit_runtime_invoke + 722
	40  mono-sgen                           0x001a4c8a mono_runtime_invoke + 170
	41  mono-sgen                           0x0019e89a mono_runtime_class_init_full + 1946
	42  mono-sgen                           0x0000c8a8 mono_jit_compile_method_with_opt + 2504
	43  mono-sgen                           0x0000ccc9 mono_jit_compile_method + 41
	44  mono-sgen                           0x0019f433 mono_compile_method + 83
	45  mono-sgen                           0x000963fb common_call_trampoline + 1083
	46  mono-sgen                           0x000939cb mono_magic_trampoline + 59
	47  ???                                 0x0043b066 0x0 + 4436070
	48  ???                                 0x007f6f0c 0x0 + 8351500
	49  ???                                 0x007f6e1c 0x0 + 8351260
	50  ???                                 0x007aafb0 0x0 + 8040368
	51  ???                                 0x00487de8 0x0 + 4750824
	52  ???                                 0x00487e9b 0x0 + 4751003
	53  mono-sgen                           0x0000cff2 mono_jit_runtime_invoke + 722
	54  mono-sgen                           0x001a4c8a mono_runtime_invoke + 170
	55  mono-sgen                           0x001a7821 mono_runtime_exec_main + 705
	56  mono-sgen                           0x001a6a31 mono_runtime_run_main + 929
	57  mono-sgen                           0x00067ee5 mono_jit_exec + 149
	58  mono-sgen                           0x0006a473 mono_main + 9603
	59  mono-sgen                           0x00002009 main + 441
	60  mono-sgen                           0x00001e16 start + 54

Debug info from gdb:


=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

Abort trap: 6
Comment 1 Zoltan Varga 2012-01-23 21:25:13 UTC
Please try 2.10.8.1.
Comment 2 Jonathan Shore 2012-01-24 07:53:28 UTC
I downloaded the OSX 2.10.8.1_2 installer and installed.   mono -version still reports 2.10.8, built on Dec 19th.   Does the installer put 2.10.8.1 in an unusual place (i.e. not in /Library/Frameworks/Mono.framework?   Or is the build date correct?

In any case, is exhibiting the same SEGV behavior.   Perhaps, though the install ran (and I tried it twice), either installed in another location or silently did not complete?
Comment 3 Jonathan Shore 2012-01-24 07:56:30 UTC
Found it in /usr/local/mono.   Same problem (though does not report the trace)

karma:Tests jshore$ /usr/local/mono/bin/mono-sgen bin/Debug/Test.exe
Segmentation fault: 11
karma:Tests jshore$ /usr/local/mono/bin/mono-sgen --llvm bin/Debug/Test.exe
Segmentation fault: 11
karma:Tests jshore$ /usr/local/mono/bin/mono-sgen --version
Mono JIT compiler version 2.10.8.1 (mono-2-10/bc36fbe Sun Dec 18 16:27:26 EST 2011)
Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       normal
	Notification:  kqueue
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	LLVM:          supported, not enabled.
	GC:            sgen
Comment 4 Jonathan Shore 2012-01-24 07:58:23 UTC
(oh, the above may have been an old build I had?   What build date should the runtime have?)
Comment 5 Jonathan Shore 2012-01-24 09:11:45 UTC
I took the latest from the mono-2-10-8 branch and the latest from the llvm mono-2-10 branch and did a build into /usr/local.

./autogen.sh --prefix=/usr/local/mono --with-glib=embedded --enable-nls=no --host=x86_64-apple-darwin10 --with-large-heap=yes

I did include "with-large-heap", but that should hopefully not be material.   The bug manifests on the standard distribution as well as on the latest build, as above.

Let me see if I can reduce this test to something smaller and post here ...
Comment 6 Zoltan Varga 2012-01-24 09:52:45 UTC
Your original report contained this assert:

* Assertion at sgen-gc.c:2506, condition `mono_sgen_need_bridge_processing ()'
not met

and that assert is no longer there on the mono 2.10 branch. Are you running into a  different problem now ?
Comment 7 Jonathan Shore 2012-01-24 10:00:00 UTC
The 65bit 2.10.8.1_x build crashes immediately with a segmentation fault (when run with sgen).  It does not show the stack trace.  How do I enable that?

karma:Tests jshore$ /usr/local/mono/bin/mono-sgen  --llvm bin/Debug/Test.exe
Segmentation fault: 11
karma:Tests jshore$ /usr/local/mono/bin/mono-sgen  bin/Debug/Test.exe
Segmentation fault: 11

The same command, but with mono boehm works fine.
Comment 8 Zoltan Varga 2012-01-24 10:21:52 UTC
I'm not sure our osx 64 bit sgen support is complete.
Comment 9 Jonathan Shore 2012-01-24 10:28:40 UTC
ok, I'll rebuild for 32bit ...
Comment 10 Jonathan Shore 2012-01-24 11:06:46 UTC
The 32bit version of the latest 2.10.8 branch appears to work properly.   sgen / 64bit (at least on osx) crashes.  Thanks
Comment 11 Rodrigo Kumpera 2012-04-22 22:59:33 UTC
Sgen was broken in 2.10.8. Is was fixed on 2.10.9