Re: [Mono-dev] Mono Weather Report 2017-08-17

2017-08-18 Thread Rolf Kvinge via Mono-devel-list 
Yes, we were using Xcode 8.3 when this test failed.

From: Alexander Köplinger 
Date: Friday, 18 August 2017 at 13:08
To: Rolf Bjarne Kvinge 
Cc: Connor Adsit , Xamarin - runtime 
, "mono-devel-list@lists.dot.net" 

Subject: Re: Mono Weather Report 2017-08-17

It looks like this one started too when we upgraded to Xcode 8.3 (like 
TestSynchronizationReleasedOnMultipleAcquire and pinvoke2.exe).
I grepped all of our Jenkins logs and the Delay_Simple test never failed before 
the upgrade.

Rolf: I assume you're using that Xcode or a newer one as well?

- Alex

On 18 Aug 2017, at 11:11, Rolf Kvinge 
> wrote:

Hi,

Xamarin.Mac has run into #9 ("Test failure in 
MonoTests.System.Threading.Tasks.TaskTests.Delay_Simple [New]") a few times too:

Bug #58235 - [jenkins] Random mscorlib test failure 
(MonoTests.System.Threading.Tasks.TaskTests.Delay_Simple)

Rolf

From: Connor Adsit >
Date: Friday, 18 August 2017 at 00:46
To: Xamarin - runtime >, 
"mono-devel-list@lists.dot.net" 
>
Subject: Mono Weather Report 2017-08-17

Salutations, all. Xamarin Release Engineering here with this week’s edition of 
the Mono Weather Report. Apologies for missing last week’s report.

Here are the top failures currently making Jenkins builds unstable:


1. Test failure in 
MonoTests.System.Runtime.Remoting.SynchronizationAttributeTest.TestSynchronizationReleasedOnMultipleAcquire
 [New]

This failure occurs exclusively on Mac and failed 69 times this past week. My 
personal hunch is that this is a result of upgrading to the latest Xcodes and 
possibly Sierra which occurred a couple weeks ago.

MESSAGE:
  Thread didn't get lock of 
context bound object.
  Expected: True
  But was:  False

+++
STACK TRACE:
  at 
MonoTests.System.Runtime.Remoting.SynchronizationAttributeTest.TestSynchronizationReleasedOnMultipleAcquire
 () [0x00032] in 
/Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/corlib/Test/System.Runtime.Remoting/SynchronizationAttributeTest.cs:345
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
(System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, 
System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, 
System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] 
in 
/Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/corlib/System.Reflection/MonoMethod.cs:305


Examples:
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/6934/testReport/(root)/SynchronizationAttributeTest/TestSynchronizationReleasedOnMultipleAcquire/
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-amd64/6937/testReport/(root)/SynchronizationAttributeTest/TestSynchronizationReleasedOnMultipleAcquire/
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-amd64/6938/testReport/(root)/SynchronizationAttributeTest/TestSynchronizationReleasedOnMultipleAcquire/


2. Test failure in MonoTests.runtime.pinvoke2.exe [New]

Occurred 46 times this week exclusively on Mac Intel32. Possibly also related 
to the software upgrades that happened earlier.

   MESSAGE:
* Assertion at libtest.c:1359, 
condition `a == 42' not met


+++
STACK TRACE:
Stacktrace:

  at  <0x>
  at (wrapper managed-to-native) Tests.mono_test_return_empty_struct (int) 
<0x00012>
  at Tests.test_0_marshal_empty_struct () [0x0001c] in 
:0
  at (wrapper runtime-invoke) .runtime_invoke_int 
(object,intptr,intptr,intptr) [0x00052] in :0
  at  <0x>
  at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke 
(System.Reflection.MonoMethod,object,object[],System.Exception&) <0x00012>

Examples:
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/6947/testReport/MonoTests/runtime/pinvoke2_exe/
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/6928/testReport/MonoTests/runtime/pinvoke2_exe/
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/6934/testReport/MonoTests/runtime/pinvoke2_exe/


3. Test failure in

Re: [Mono-dev] Mono Weather Report 2017-08-17

2017-08-18 Thread Rolf Kvinge via Mono-devel-list 
Hi,

Xamarin.Mac has run into #9 ("Test failure in 
MonoTests.System.Threading.Tasks.TaskTests.Delay_Simple [New]") a few times too:

Bug #58235 - [jenkins] Random mscorlib test failure 
(MonoTests.System.Threading.Tasks.TaskTests.Delay_Simple)

Rolf

From: Connor Adsit 
Date: Friday, 18 August 2017 at 00:46
To: Xamarin - runtime , "mono-devel-list@lists.dot.net" 

Subject: Mono Weather Report 2017-08-17

Salutations, all. Xamarin Release Engineering here with this week’s edition of 
the Mono Weather Report. Apologies for missing last week’s report.

Here are the top failures currently making Jenkins builds unstable:


1. Test failure in 
MonoTests.System.Runtime.Remoting.SynchronizationAttributeTest.TestSynchronizationReleasedOnMultipleAcquire
 [New]

This failure occurs exclusively on Mac and failed 69 times this past week. My 
personal hunch is that this is a result of upgrading to the latest Xcodes and 
possibly Sierra which occurred a couple weeks ago.

MESSAGE:
  Thread didn't get lock of 
context bound object.
  Expected: True
  But was:  False

+++
STACK TRACE:
  at 
MonoTests.System.Runtime.Remoting.SynchronizationAttributeTest.TestSynchronizationReleasedOnMultipleAcquire
 () [0x00032] in 
/Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/corlib/Test/System.Runtime.Remoting/SynchronizationAttributeTest.cs:345
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
(System.Reflection.MonoMethod,object,object[],System.Exception&)
at System.Reflection.MonoMethod.Invoke (System.Object obj, 
System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, 
System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00032] 
in 
/Users/builder/jenkins/workspace/test-mono-mainline/label/osx-i386/mcs/class/corlib/System.Reflection/MonoMethod.cs:305


Examples:
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/6934/testReport/(root)/SynchronizationAttributeTest/TestSynchronizationReleasedOnMultipleAcquire/
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-amd64/6937/testReport/(root)/SynchronizationAttributeTest/TestSynchronizationReleasedOnMultipleAcquire/
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-amd64/6938/testReport/(root)/SynchronizationAttributeTest/TestSynchronizationReleasedOnMultipleAcquire/


2. Test failure in MonoTests.runtime.pinvoke2.exe [New]

Occurred 46 times this week exclusively on Mac Intel32. Possibly also related 
to the software upgrades that happened earlier.

   MESSAGE:
* Assertion at libtest.c:1359, 
condition `a == 42' not met


+++
STACK TRACE:
Stacktrace:

  at  <0x>
  at (wrapper managed-to-native) Tests.mono_test_return_empty_struct (int) 
<0x00012>
  at Tests.test_0_marshal_empty_struct () [0x0001c] in 
:0
  at (wrapper runtime-invoke) .runtime_invoke_int 
(object,intptr,intptr,intptr) [0x00052] in :0
  at  <0x>
  at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke 
(System.Reflection.MonoMethod,object,object[],System.Exception&) <0x00012>

Examples:
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/6947/testReport/MonoTests/runtime/pinvoke2_exe/
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/6928/testReport/MonoTests/runtime/pinvoke2_exe/
https://jenkins.mono-project.com/job/test-mono-mainline/label=osx-i386/6934/testReport/MonoTests/runtime/pinvoke2_exe/


3. Test failure in 
MonoTests.System.Net.Sockets.SocketTest.ConcurrentExceedSocketLimit [New]

Occurred 14 times this week on Linux ARM.

MESSAGE:
System.AggregateException : One 
or more errors occurred.
  > System.Net.Sockets.SocketException : Address already in use
+++
STACK TRACE:
  at 
System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks, 
System.Int32 millisecondsTimeout, System.Threading.CancellationToken 
cancellationToken) [0x001d2] in 
/media/ssd/jenkins/workspace/test-mono-mainline-linux/label/debian-8-arm64/mcs/class/referencesource/mscorlib/system/threading/Tasks/Task.cs:5174
  at System.Threading.Tasks.Task.WaitAll (System.Threading.Tasks.Task[] tasks, 
System.Int32

Re: [Mono-dev] [android-devel] [macios-devel] Signal-chaining & crash reporters

2016-09-23 Thread Rolf Kvinge via Mono-devel-list 
Hi,


I've tried implementing this, here's a Mono PR for it: 
https://github.com/mono/mono/pull/3624


I'm not where to document the new managed API though.


Rolf


Sent from Outlook


From: Rodrigo Kumpera
Sent: Thursday, September 22, 2016 11:05:07 PM
To: Miguel de Icaza; Rolf Kvinge
Cc: macios-de...@lists.dot.net; mono-devel-list@lists.dot.net; 
android-de...@lists.dot.net
Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters

Hey,

Given Rolf's constraints, I don't think we can do reasonably better than your 
proposal.

--
Rodrigo


From: Miguel de Icaza 
Date: Tuesday, September 20, 2016 at 6:01 AM
To: Rolf Kvinge , Rodrigo Kumpera 

Cc: "macios-de...@lists.dot.net" , 
"mono-devel-list@lists.dot.net" , 
"android-de...@lists.dot.net" 
Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters

Hello,

My proposal addressed that, the downside is that there is a window at startup 
where the runtime will not catch exceptions properly.

I think it is fair to document the limitation of the technique in those 
scenarios.

From: Rolf Kvinge 
Date: Tuesday, September 20, 2016 at 5:17 AM
To: Rodrigo Kumpera 
Cc: Miguel de Icaza , "macios-de...@lists.dot.net" 
, "mono-devel-list@lists.dot.net" 
, "android-de...@lists.dot.net" 

Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters




Hi Rodrigo,



I think we should first decide how we want to expose this in managed code, 
since using your idea I don't see any options besides those I initially 
proposed (and which Miguel didn't like).



One of the problems is that there's a lot of people involved here:



1) The native library that detects crashes and collects crash information. On 
iOS this is typically PLCrashReporter [1].



2) Companies that build native crash reporting solutions on top of libraries 
from 1). On iOS this is HockeyApp, Insights, Crittercism, Flurry (which all use 
PLCrashReporter I believe), Crashlytics (which is not using PLCrashReporter, 
they wrote their own replacement [2]), etc.



3) The managed bindings for the products in 2). Some of these we maintain 
ourselves (in the component store - Crittercism [3]), some are maintained by 
those companies themselves (HockeyApp [4]), and some I believe are community 
supported/written.



4) Us.



5) The app (developer).



Ideally whatever we come up with should require changes from as few of these as 
possible, the best case scenario being #3 only (besides ourselves of course). 
Any changes to #1 will likely require changes to #2 as well.



Rolf



[1] https://plcrashreporter.org

[2] 
http://stackoverflow.com/questions/14041789/comparison-between-testflight-live-quincykit-and-crashlytics#comment19667280_14103776

[3] https://components.xamarin.com/gettingstarted/crittercism

[4] https://github.com/bitstadium/HockeySDK-Xamarin



Sent from Outlook


From: Rodrigo Kumpera
Sent: Monday, September 19, 2016 8:51:02 PM
To: Rolf Kvinge
Cc: Miguel de Icaza; macios-de...@lists.dot.net; mono-devel-list@lists.dot.net; 
android-de...@lists.dot.net
Subject: Re: [android-devel] [macios-devel] Signal-chaining & crash reporters

Hey Rolf,

On your suggestion, I'm not sure that's exactly what we want.
Even though we can ask user to do signal chaining themselves, I don't think 
it's necessary. I don't think we should be promoting the broken design of posix 
signals around. ;)
Another thing is that this design is not portable and exposes a bit too much of 
mono internals.

What about this: https://gist.github.com/569e860dd7e73bde0d8d098f95143662

It probably won't compile as I normalized the signature of 
mono_handle_native_sigsegv with other similar functions.

--
Rodrigo


On 9/19/16, 3:25 AM, "Rolf Kvinge"  wrote:


Hi,

> From: Rodrigo Kumpera
>
>
> Hey guys,
>
>  Exposing signal handlers from managed code is always the wrong solution.
>
>
>
> If we're crashing in the runtime, a managed code signal handler has very 
little chance of works. It's a scenario we will never even consider supporting.

This is not about exposing signal handlers to managed code, the signal 
handlers we want called are always in native code.

>
>
>
> I guess the simple solution is to add an embedding API call that queues 
signal handlers
> to be called first before chaining to the OS one.

Something like this: 
https://gist.github.com/rolfbjarne/6aab59c1609f33402d195f9c34e9f99b?

Rolf

Re: [Mono-dev] [macios-devel] Signal-chaining & crash reporters

2016-09-19 Thread Rolf Kvinge via Mono-devel-list 
c.c. the android  + monodev email list to keep thosein the loop (other 
responses have been sent there too)

On 16/09/16 19:22, "Miguel de Icaza"  wrote:

Hello,

Thanks for getting these proposals out Rolf.

I am not a fan of any of the provided options.

We have two issues here: Mono is doing the right thing by supporting “chained 
handlers”, but many of these libraries can not chain signal handlers.

Let me propose that we add a pair of methods, to undo the signal handling 
setup, and to restore the handling setup and surface those to managed code.

The code for things like HockeyApp would become:

Mono.UndoSignalHandlingSetup ();// SIGSEGV points back 
to original handlers
HockeyAppInstallHandlers ();// SIGSEGV now points 
to HockeyApp handlers
Mono.InstallSignalHandlers ();  // SIGSEGV now points 
to Mono handler, that have chained capabilities

The Undo/Install is necessary for the rare case of a library that can do proper 
chaining and might want to chain to another handler, so they would not chain 
back to Mono.

Miguel.



___
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [android-devel] [macios-devel] Signal-chaining & crash reporters

2016-09-19 Thread Rolf Kvinge via Mono-devel-list 

Hi,

> From: Rodrigo Kumpera
>   
> 
> Hey guys,
> 
>  Exposing signal handlers from managed code is always the wrong solution.
> 
> 
> 
> If we're crashing in the runtime, a managed code signal handler has very 
> little chance of works. It's a scenario we will never even consider 
> supporting.

This is not about exposing signal handlers to managed code, the signal handlers 
we want called are always in native code.

> 
> 
> 
> I guess the simple solution is to add an embedding API call that queues 
> signal handlers
> to be called first before chaining to the OS one.

Something like this: 
https://gist.github.com/rolfbjarne/6aab59c1609f33402d195f9c34e9f99b?

Rolf
___
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [macios-devel] Signal-chaining & crash reporters

2016-09-16 Thread Rolf Kvinge via Mono-devel-list 
Hi,

> On 16/09/16 19:22, "Miguel de Icaza"  wrote:
> 
> Hello,
> 
> Thanks for getting these proposals out Rolf.
> 
> I am not a fan of any of the provided options.
> 
> We have two issues here: Mono is doing the right thing by supporting “chained 
> handlers”, but many of these libraries can not chain signal handlers.
> 
> Let me propose that we add a pair of methods, to undo the signal handling 
> setup, and to restore the handling setup and surface those to managed code.
> 
> The code for things like HockeyApp would become:
> 
>   Mono.UndoSignalHandlingSetup ();// SIGSEGV points back 
> to original handlers
>   HockeyAppInstallHandlers ();// SIGSEGV now points 
> to HockeyApp handlers
>   Mono.InstallSignalHandlers ();  // SIGSEGV now points 
> to Mono handler, that have chained capabilities
> 
> The Undo/Install is necessary for the rare case of a library that can do 
> proper chaining and might want to chain to another handler, so they would not 
> chain back to Mono.

I think this could work.

Another advantage is that it would not require any code changes in the 
products, only Mono.

I can have a look at implementing (and testing) this, unless the runtime team 
wants to do it?

Rolf

___
macios-devel mailing list
macios-de...@lists.dot.net
http://lists.dot.net/mailman/listinfo/macios-devel


___
Mono-devel-list mailing list
Mono-devel-list@lists.dot.net
http://lists.dot.net/mailman/listinfo/mono-devel-list