Bug 11048 - TrustEvaluateSsl will cause a SIGSEGV
Summary: TrustEvaluateSsl will cause a SIGSEGV
Alias: None
Product: iOS
Classification: Xamarin
Component: General ()
Version: 6.2.x
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2013-03-11 14:23 UTC by Matthijs Koopman
Modified: 2013-12-05 18:36 UTC (History)
2 users (show)

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 Developer Community or GitHub 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:

Description Matthijs Koopman 2013-03-11 14:23:17 UTC
In some cases validating a request made over SSL will cause a SIGSEGV sadly enough it's really hard to reproduce but it occurs sometimes. Here is the stacktrace...


  at Mono.Security.X509.OSX509Certificates.TrustEvaluateSsl (Mono.Security.X509.X509CertificateCollection,string) [0x00008] in /Developer/MonoTouch/Source/mono/mcs/class/System/System.Security.Cryptography.X509Certificates/OSX509Certificates.cs:95
  at System.Net.ServicePointManager/ChainValidationHelper.ValidateChain (Mono.Security.X509.X509CertificateCollection) [0x000af] in /Developer/MonoTouch/Source/mono/mcs/class/System/System.Net/ServicePointManager.cs:501
  at Mono.Security.Protocol.Tls.SslClientStream.OnRemoteCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) [0x0000d] in /Developer/MonoTouch/Source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs:423
  at Mono.Security.Protocol.Tls.SslStreamBase.RaiseRemoteCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslStreamBase.cs:210
  at Mono.Security.Protocol.Tls.SslClientStream.RaiseServerCertificateValidation2 (Mono.Security.X509.X509CertificateCollection) [0x00000] in /Developer/MonoTouch/Source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/SslClientStream.cs:446
  at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates (Mono.Security.X509.X509CertificateCollection) [0x0001f] in /Developer/MonoTouch/Source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls.Handshake.Client/TlsServerCertificate.cs:198
  at Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 () [0x00054] in /Developer/MonoTouch/Source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls.Handshake.Client/TlsServerCertificate.cs:105
  at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () [0x00037] in /Developer/MonoTouch/Source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls.Handshake/HandshakeMessage.cs:105
  at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage (Mono.Security.Protocol.Tls.TlsStream) [0x00039] in /Developer/MonoTouch/Source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/ClientRecordProtocol.cs:81
  at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback (System.IAsyncResult) [0x00127] in /Developer/MonoTouch/Source/mono/mcs/class/Mono.Security/Mono.Security.Protocol.Tls/RecordProtocol.cs:397
  at (wrapper runtime-invoke) <Module>.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <IL 0x00052, 0xffffffff>

Native stacktrace:

	0   MyExeName                             0x00095e6c mono_handle_native_sigsegv + 284
	1   MyExeName                             0x0000bb48 mono_sigsegv_signal_handler + 248
	2   libsystem_c.dylib                   0x900b586b _sigtramp + 43
	3   ???                                 0xffffffff 0x0 + 4294967295
	4   MyExeName                             0x000ef281 mono_class_from_name + 49
	5   MyExeName                             0x0016762c mono_mb_emit_exception_full + 44
	6   MyExeName                             0x0016779f mono_mb_emit_exception + 47
	7   MyExeName                             0x00143a96 mono_marshal_get_native_wrapper + 870
	8   MyExeName                             0x00038032 mono_method_to_ir + 51586
	9   MyExeName                             0x00011f88 mini_method_compile + 1144
	10  MyExeName                             0x00014381 mono_jit_compile_method_with_opt + 1233
	11  MyExeName                             0x0000fbd9 mono_jit_compile_method + 41
	12  MyExeName                             0x00099679 common_call_trampoline + 1097
	13  MyExeName                             0x00096bcb mono_magic_trampoline + 59
	14  ???                                 0x0b60d066 0x0 + 190894182
	15  ???                                 0x17f9a4d4 0x0 + 402236628
	16  ???                                 0x17f9a038 0x0 + 402235448
	17  ???                                 0x17f99f7b 0x0 + 402235259
	18  ???                                 0x17f99ee8 0x0 + 402235112
	19  ???                                 0x17f9879f 0x0 + 402229151
	20  ???                                 0x17cc2020 0x0 + 399253536
	21  ???                                 0x17cb21b2 0x0 + 399188402
	22  ???                                 0x17cbd500 0x0 + 399234304
	23  ???                                 0x17cbb214 0x0 + 399225364
	24  ???                                 0x0b769c8e 0x0 + 192322702
	25  MyExeName                             0x0000ff02 mono_jit_runtime_invoke + 722
	26  MyExeName                             0x0017482e mono_runtime_invoke + 126
	27  MyExeName                             0x0017499c mono_runtime_delegate_invoke + 140
	28  MyExeName                             0x001ceda4 async_invoke_thread + 1940
	29  MyExeName                             0x001d4b46 start_wrapper + 438
	30  MyExeName                             0x00206a8a thread_start_routine + 154
	31  MyExeName                             0x001b1930 gc_start_thread + 80
	32  libsystem_c.dylib                   0x900c9557 _pthread_start + 344
	33  libsystem_c.dylib                   0x900b3cee thread_start + 34

Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
Comment 1 Sebastien Pouliot 2013-03-12 08:37:11 UTC
I need:

* a test case, at a minimum an URL where this *has* occured;

* all the version information (Xamarin Studio can give it all to you);
Comment 2 Matthijs Koopman 2013-03-12 08:55:16 UTC
It's really hard to provide a descent test case because the issue does occur occasionally.

But it occurred on different URLs, e.g.:


But alo occured on Facebook URLs

And the version info:

Xamarin Studio
Version 4.0.1 (build 9)
Installation UUID: aeb8f0e1-6115-42aa-aece-52050bf40cf8
	Mono 2.10.11 (mono-2-10/2baeee2)
	GTK 2.24.14
	GTK# (
	Package version: 210110000

Not Installed

Apple Developer Tools
Xcode 4.6 (2066)
Build 4H127

Xamarin.Mac: Not Installed

Version: (Enterprise Edition)

Build Information
Git revision: Release ID: 400010009
Build date: 2013-03-05 17:24:34+0000
Xamarin addins: 181e75e43f263f1c0783b9f7e32234cac6850998

Operating System
Mac OS X 10.8.2
Darwin ---.local 12.2.0 Darwin Kernel Version 12.2.0
    Sat Aug 25 00:48:52 PDT 2012
    root:xnu-2050.18.24~1/RELEASE_X86_64 x86_64
Comment 3 Sebastien Pouliot 2013-03-12 09:02:53 UTC
The stack trace looks incomplete. Can you get a crash report from the device ?

And also your build options (e.g. LLVM) or a full build log will show everything.
Comment 4 Matthijs Koopman 2013-03-12 09:17:47 UTC
This is truly the entire stacktrace, it occurred on the emulator so i don't have a crash report for you.

I did add the build log, but removed all the project related structure information.

Building: app (Debug|iPhoneSimulator)
Performing main compilation...
/Developer/MonoTouch/usr/bin/smcs /noconfig "/out:/Users/[path_to_project]/bin/iPhoneSimulator/Debug/app.exe" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Core.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.ServiceModel.Web.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Web.Services.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.Linq.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Data.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Runtime.Serialization.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.ServiceModel.dll" "/r:/Users/[path_to_project]/External/lib.dll" "/r:/Developer/MonoTouch/usr/lib/mono/2.1/System.Numerics.dll" /nologo /warn:4 /debug:full /optimize- /codepage:utf8 "/define:DEBUG;IPHONE;MONOTOUCH;VERBOSE;STRICT"  /t:exe [files]

Compiling to native code
/Developer/MonoTouch/usr/bin/mtouch -sdkroot "/Applications/Xcode.app/Contents/Developer" -v --cache "/Users/[path_to_project]/obj/Debug/mtouch-cache" --nomanifest --nosign -sim "/Users/[path_to_project]/bin/iPhoneSimulator/Debug/myapp.app" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Core.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/monotouch.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.ServiceModel.Web.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Web.Services.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Xml.Linq.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Data.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Runtime.Serialization.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.ServiceModel.dll" -r "/Users/[path_to_project]/External/lib.dll" -r "/Developer/MonoTouch/usr/lib/mono/2.1/System.Numerics.dll" -debug -profiling -nolink -sdk "6.1" -targetver "5.0" --sgen --abi=i386 "-nolinkaway" "-aot" "nimt-trampolines=512" "/Users/[path_to_project]/bin/iPhoneSimulator/Debug/app.exe"
MonoTouch Priority version 6.2.0 using framework: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk

Extracting embedded content

Updating application manifest

Updating debug configuration file

Updating debug settings manifest

---------------------- Done ----------------------

Apple iPhone SDK version '5.0' is not installed. Using newer version '6.1' instead'.
Build: 0 errors, 466 warnings
Comment 5 Sebastien Pouliot 2013-03-12 09:39:30 UTC
Using the iOS simulator explains some of the stacktrace weirdness (and it's a pretty important information to give in bug reports). The native stacktrace points to the JIT, which is not used for devices.

Have you ever got a similar crash on devices ?

Note that those options should not be defined (they do nothing) for simulator builds: "-nolinkaway" "-aot" "nimt-trampolines=512"

* the first one should only be used in rare circumstances (it only bundle extra code when linking is enabled, which it's not for the simulator build);
* the second option is not needed anymore on recent releases (it's automagically adjusted);
Comment 6 Matthijs Koopman 2013-03-12 09:41:47 UTC
We have seen it on devices but sadly enough i do not have the crashreports for you.
Comment 7 Sebastien Pouliot 2013-03-12 17:24:27 UTC
They are less useful (in general and even less in this case*) but you can find crash reports for the iOS Simulator inside OSX Console.app

Right now it seems the JIT was trying to emit code to throw an exception and the type was not found. However the linker is disabled in your simulator builds and it works most of the time.

* the crash can't be identical but it might give an hint to the original (shared) cause

Also if you can duplicate this a few times it would be worth trying the simulator without --sgen (i.e. disabling sgen) to see if this *might* influence the crash probability.
Comment 8 PJ 2013-11-19 17:05:35 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 9 PJ 2013-12-05 18:36:02 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.