Bug 39430 - The ViewExtensions library can crashes internally.
Summary: The ViewExtensions library can crashes internally.
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.0.1
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-03-08 00:44 UTC by Andy
Modified: 2017-06-16 17:03 UTC (History)
7 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 Andy 2016-03-08 00:44:34 UTC

I looked at some of the source, and it seems to me that the call to SetResult can throw an exception. That exception doesn't appear to be caught internally.

My line of code is "someView.TranslateTo(0.0, 0.0, 50);"

System.InvalidOperationExceptionAn attempt was made to transition a task to a final state when it had already completed.

  at System.Threading.Tasks.TaskCompletionSource`1[TResult].SetResult (System.Threading.Tasks.TResult result) [0x0000c] in /Users/builder/data/lanes/2689/962a0506/source/maccore/_build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/src/mono/external/referencesource/mscorlib/system/threading/Tasks/TaskCompletionSource.cs:322 
  at Xamarin.Forms.ViewExtensions+<>c__DisplayClass0_0.<TranslateTo>b__2 (Double f, Boolean a) [0x00000] in <filename unknown>:0 
  at Xamarin.Forms.AnimationExtensions+<>c__DisplayClass10_0`1[T].<Animate>b__1 (Double f, Boolean b) [0x00012] in <filename unknown>:0 
  at Xamarin.Forms.AnimationExtensions.AbortAnimation (Xamarin.Forms.AnimatableKey key) [0x0005c] in <filename unknown>:0 
  at Xamarin.Forms.AnimationExtensions.Animate[T] (IAnimatable self, System.String name, System.Func`2 transform, System.Action`1 callback, UInt32 rate, UInt32 length, Xamarin.Forms.Easing easing, System.Action`2 finished, System.Func`1 repeat) [0x0005d] in <filename unknown>:0 
  at Xamarin.Forms.AnimationExtensions.Animate (IAnimatable self, System.String name, System.Action`1 callback, UInt32 rate, UInt32 length, Xamarin.Forms.Easing easing, System.Action`2 finished, System.Func`1 repeat) [0x00000] in <filename unknown>:0 
  at Xamarin.Forms.AnimationExtensions.Animate (IAnimatable self, System.String name, Xamarin.Forms.Animation animation, UInt32 rate, UInt32 length, Xamarin.Forms.Easing easing, System.Action`2 finished, System.Func`1 repeat) [0x00008] in <filename unknown>:0 
  at Xamarin.Forms.Animation.Commit (IAnimatable owner, System.String name, UInt32 rate, UInt32 length, Xamarin.Forms.Easing easing, System.Action`2 finished, System.Func`1 repeat) [0x00000] in <filename unknown>:0 
  at Xamarin.Forms.ViewExtensions.TranslateTo (Xamarin.Forms.VisualElement view, Double x, Double y, UInt32 length, Xamarin.Forms.Easing easing) [0x000a5] in <filename unknown>:0
Comment 1 Paul DiPietro [MSFT] 2016-03-10 19:49:18 UTC
If you could possibly provide a sample reproduction project running on the latest stable showing a scenario where this would occur, it would be appreciated in helping to investigate the issue.
Comment 2 Andy 2016-03-10 19:51:36 UTC
Can't you just look at the code and see the exception that it isn't handling?
Comment 3 Jason Smith [MSFT] 2016-03-13 11:54:32 UTC
Paul is just helping us make sure we have all the info we need to address a bug. I can see where the crash is obviously happening, the bigger question is what is happening to trigger Finished to be called twice...

It looks like AbortAnimation is being called, no chance you are calling TranslateTo a lot or maybe from a thread?
Comment 4 Night Owl 2016-03-17 04:05:28 UTC
Hey Jason, what you mean by calling it a lot?
Is there a limit?

We need to ship our app ASAP but since update to all animations started to behave totally crazy.

I got the same bug as above, and for repro just add a label and animate it, and move to next page.

Also, I'm getting a lot of "this must be run for the UI thread checks", on a sequence like this, that DOES start on the UI thread:

        private async Task ExecuteStoryboardAsync()
            await LogoImage.ScaleTo(0.25f, length: 500, easing: Easing.CubicOut);
            await LogoImage.ScaleTo(25, length: 500, easing: Easing.CubicIn);
Comment 5 Night Owl 2016-03-17 04:07:07 UTC
Submitted too soon, sorry...

The failed check happens on the second ScaleTo, looks like the continuation is not been called on the UI Thread!
Comment 6 Jason Smith [MSFT] 2016-03-17 06:46:39 UTC
There is no limit, I am just trying to figure out how to trigger the issue.
Comment 7 Jason Smith [MSFT] 2016-03-17 06:48:05 UTC
Does wrapping the call into a BeginInvokeOnMainThread fix it? We dont do the martial back to the UIThread, that is done by the await mechanism
Comment 8 Andy 2016-03-31 13:32:23 UTC
Can't you just look at the code and see that it throws an exception which is not handled?
Comment 9 Jeff Dalby 2016-06-19 18:04:07 UTC
We've run into this as well.  It's hard to reproduce with any sort of consistency, but seems to happen on older devices when you have a button with an animation to shrink it on tap, and you double or triple tap it cause you are impatient at the slow device :-).  The code below is the relevant part from the tapped event.

if (!isAnimating)
 isAnimating = true;
 myButton.AnchorX = 0.5;
 myButton.AnchorY = 0.5;
 await myButton.ScaleTo(0.50, 75, Easing.SinOut);
 await myButton.ScaleTo(1, (uint) 75, Easing.SinIn);
 isAnimating = false;

We added the isAnimating check as an attempt to stop it from trying to run the animation if it was already in progress. Originally the scale to's were run using Device.BeginInvokeOnMainThread, but with the latest 2.2 or 2.3 Forms update where animations were all changed to run on main thread we had to remove that.

here's a log from a crash:

	at System.Threading.Tasks.TaskCompletionSource`1[TResult].SetResult(System.Threading.Tasks.TResult_result.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.ViewExtensions+<>c__DisplayClass8_0.<ScaleTo>b__1(Double_f__Boolean_a.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.AnimationExtensions+<>c__DisplayClass13_0`1[T].<AnimateInternal>b__1(Double_f__Boolean_b.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.AnimationExtensions.AbortAnimation(Xamarin.Forms.AnimatableKey_key.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.AnimationExtensions.AnimateInternal[T](IAnimatable_self__System.String_name__System.Func`2_transform__System.Action`1_callback__UInt32_rate__UInt32_length__Xamarin.Forms.Easing_easing__System.Action`2_finished__System.Func`1_repeat.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.AnimationExtensions+<>c__DisplayClass7_0`1[T].<Animate>b__0(.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.AnimationExtensions.Animate[T](IAnimatable_self__System.String_name__System.Func`2_transform__System.Action`1_callback__UInt32_rate__UInt32_length__Xamarin.Forms.Easing_easing__System.Action`2_finished__System.Func`1_repeat.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.AnimationExtensions.Animate(IAnimatable_self__System.String_name__System.Action`1_callback__UInt32_rate__UInt32_length__Xamarin.Forms.Easing_easing__System.Action`2_finished__System.Func`1_repeat.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.AnimationExtensions.Animate(IAnimatable_self__System.String_name__Xamarin.Forms.Animation_animation__UInt32_rate__UInt32_length__Xamarin.Forms.Easing_easing__System.Action`2_finished__System.Func`1_repeat.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.Animation.Commit(IAnimatable_owner__System.String_name__UInt32_rate__UInt32_length__Xamarin.Forms.Easing_easing__System.Action`2_finished__System.Func`1_repeat.args:1337)
	at com.wefeel.wefeelapp.Xamarin.Forms.ViewExtensions.ScaleTo(Xamarin.Forms.VisualElement_view__Double_scale__UInt32_length__Xamarin.Forms.Easing_easing.args:1337)
	at com.wefeel.wefeelapp.WeFeelXamarin.Controls.ImageToggleOutlineControl+<>c__DisplayClass42_0+<<TapGesture_Tapped>b__0>d.MoveNext(.args:1337)
	at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw(.args:1337)
	at System.Runtime.CompilerServices.AsyncMethodBuilderCore.<ThrowAsync>m__0(System.Object_state.args:1337)
	at Android.App.SyncContext+<Post>c__AnonStorey0.<>m__0(.args:1337)
	at Java.Lang.Thread+RunnableImplementor.Run(.args:1337)
	at Java.Lang.IRunnableInvoker.n_Run(IntPtr_jnienv__IntPtr_native__this.args:1337)
Comment 10 Paul DiPietro [MSFT] 2016-12-05 21:56:20 UTC
I am closing this as a complete, working reproduction project of the described issue has not been provided to date. If someone is able to do so, please feel free to reopen this and attach said project and we'll look into it.
Comment 11 Nick Kovalsky 2017-06-16 17:03:43 UTC

Must be same problem. Was using ScaleTo.

Crash when opening drawer menu on iOS, while having animations running on main ui thread. Happens instantly of after a number of clicks, totally random, but 100% to happen.

The project was crated from blank app, added 3 files : root, master and detail, nothing unusual, nothing special.
Just lauch app, no matter simulator or real device, no matter release or debug.
Start clicking on the left upper corner opening and closing menu.
This menu animation will suddenly (from instant to up to like 5-7 minutes) conflict with your image animation that is run on main UI thread.
Just don't stop clicking..

Read other file in same dir for crash log, that ends by 
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.