Xamarin.forms: [Ошибка] InvalidOperationException в TypedBinding`2 [TSource, TProperty] .Apply

@mfeingol Если вы можете сузить

Я постараюсь сделать это в эти выходные, но это сложно воспроизвести по запросу. Есть какие-нибудь подсказки с вашей стороны, основанные на вашем понимании кода?

Похоже, это связано с привязкой XAML с использованием DataType.

Сейчас я путешествую, но моим временным решением было отключить скомпилированные привязки.

@mfeingol Ладно, звучит правильно. Если у вас будет возможность, предоставьте образец проекта, который поможет нам решить проблему. Благодаря!

Я наблюдаю ту же проблему как на iOS, так и на Android. Я не использую скомпилированные привязки.

Проблема с AppCenter:

TypedBinding 2[TSource,TProperty].Apply (System.Boolean fromTarget) TypedBinding 2 + PropertyChangedProxy [TSource, TProperty].b__16_0 ()
Поток + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this)
(динамический метод оболочки) System.Object.26 (intptr, intptr)

Проект форм Xamarin, страница Xaml с ViewModel - Grid, содержащая ScrollView - ScrollView содержит метки. Довольно просто.

@samhouts : Я старался изо всех

Могу ли я предоставить кому-либо из вашей группы разрешения на мой проект Azure DevOps, чтобы они могли воспроизвести проблему?

шнеувил на microsoft.com

Вы находитесь: https://dev.azure.com/sideroads/Sideroads

Шаги воспроизведения:

1. git checkout 6698-repro и сборка. Возможно, вам потребуется добавить внешний каталог в список каталогов NuGet, чтобы получить пакет.
2. Запустите приложение и создайте новую поездку на странице поездок. Назовите поездку как-то вроде "Test" и оставьте все значения по умолчанию, кроме указания отправления и прибытия и аэропортов (например, SEA и LAS).
3. Коснитесь поездки, чтобы выбрать ее.
4. В гамбургер-меню перейдите на страницу погоды и убедитесь, что отчеты о погоде отображаются для соответствующих мест.
5. Заходим в настройки, меняем поставщика погоды с NWS на ЗДЕСЬ.
6. Вернитесь на страницу погоды. Вы должны довольно быстро увидеть сбой. После перезапуска приложение должно снова открыться на странице погоды, обновить погоду и вызвать еще один сбой.

Если по какой-то причине вы не можете воспроизвести такую ​​простую поездку, я экспортирую для вас более сложную с большим количеством мест.

@PureWeen : дайте мне знать, если это не

@mtirona : Я пропустил ваш комментарий ранее, извините. Странно, что вы видите это без использования скомпилированных привязок. Я не думаю, что у вас есть простой репро-проект, который вызывает сбой по запросу?

@mfeingol Эта проблема случайно появляется в нашем приложении. У меня нет простого воссоздания по запросу - у меня есть сотни сбоев в AppCenter, документирующих проблему. Буду признателен за любые указания, как предотвратить проблему ...

@mtirona : вы на 100% уверены, что не используете x: DataType где-либо в своем XAML?

@mfeingol На родительских страницах был x: DataType, поэтому я просмотрел все приложение и создал ветку, в которой удалил x: DataType. Я нахожусь в процессе нашего QA-тестирования этой ветки на предмет сбоев, чтобы увидеть, решило ли это проблему.

Я на пять девяток уверен, что это связано с XamlC, если только вы не создаете TypedBindings в своем собственном коде (они _ только_ создаются компилятором Xaml)

Боковое примечание: я был на Xamarin Forms 3.6, и я только что обновился до последней версии 4.1. При первом запуске моего приложения я сразу увидел этот сбой при быстром добавлении элементов на страницу сгруппированного списка. Таким образом, проблема все еще существует с 4.1.0.618606.

@PureWeen : Я обновил приведенные выше шаги

@mfeingol, ты можешь сделать это для меня?

Если по какой-то причине вы не можете воспроизвести такую ​​простую поездку, я экспортирую для вас более сложную с большим количеством мест.

Я попробовал твои шаги, и у меня ничего не разбилось

Хорошо, итак @mfeingol Я не уверен, как и почему ваши данные выстраиваются в линию, чтобы вызвать эту проблему, но это то, что я знаю пока

TypedBindings использует WeakReference для BindableObject, поэтому, если это единственное, что ссылается на BindableObject, он потеряет эту ссылку.

Вот код, который вылетает
`` С #
если (! _weakTarget.TryGetTarget (исходящая цель))
throw new InvalidOperationException ();

If you look at the output of the application while it's running the exception always happens after a GC which makes sense why you are only seeing this after loading a larger data set.

As a test with the TypeBindings I created a nuget where it stores the source and target to a local variable just to see what would happen 

```C#
            _weakSource.SetTarget(source);
            _weakTarget.SetTarget(bindObj);
            _bindObj = bindObj;
            _source = source;
            ApplyCore(source, bindObj, targetProperty);
        }

        BindableObject _bindObj;
        object _source;

И если я это сделаю, сбоя не произойдет.

Я думаю, что каким-то образом ваши данные попадают в место, где единственное, что ссылается на экземпляр LocationDayWeatherViewModel , привязанный к ViewCell, - это TypeBinding и все. Я до сих пор не совсем понял, является ли это каким-то исключением с нашей стороны по сравнению с вашей. Можете ли вы убедиться, что поддерживаете ссылку на все созданные LocationDayWeatherViewModel , привязанные к ListView?

Спасибо, что изучили это! Эту проблему было довольно сложно воспроизвести за пределами полного приложения, поэтому имеет смысл, что это будет что-то, связанное со слабыми ссылками. Интересно, может ли добавление давления памяти к более простому воспроизведению привести к той же проблеме.

В любом случае, единственный раз, когда на экземпляр LocationDayWeatherViewModel не будет ссылаться модель просмотра, будет во время обновления дня погоды, когда код очищает привязанный ObservableCollection элементов перед вставкой новых элементов. Это происходит глубоко в ExpandableGroupCollectionViewModel.Refresh если вы хотите установить бит / с.

Однако я бы подумал, что очистка привязанной коллекции ObservableCollection должна быть безопасной операцией, и мне не очевидно, почему привязки XF будут использовать слабые ссылки. Похоже, это была бы именно такая гонка.

Кроме того: я попытался скопировать элементы в this во временный список перед очисткой в Refresh , но, к удивлению, это не помогло обойти проблему. Я действительно сослался на список в конце метода, чтобы убедиться, что сборщик мусора не уничтожил его. Я предполагаю, что это имело бы смысл, если XF пытается использовать устаревшую привязку «позже», и это говорит о том, что у приложения нет хорошего способа стабилизировать связанные ссылки. Но я могу что-то не понимать.

(И да, код погоды / экспандера немного выходит из-под контроля. Я бы хотел, чтобы у XF был собственный контроль Expander ...)

Я думаю, что добавление нехватки памяти или просто вызов GC.Collect может воссоздать проблему в меньшем проекте. Это также может произойти из-за того, что OnPropertyChanged в TypedBinding маршалируется в поток пользовательского интерфейса.

https://github.com/xamarin/Xamarin.Forms/blob/7cc9a282bdeb76405c793574ebe0d096072f4228/Xamarin.Forms.Core/TypedBinding.cs#L275

Итак, ясно, я думаю, что может случиться

PropertyChanged в очереди в потоке пользовательского интерфейса
Очистить
GC
WeakReference теряет ссылку
PropertyChanged теперь разрешает и выдает исключение

Может это связано с этим вопросом?
https://github.com/xamarin/xamarin-android/issues/2049

@StephaneDelcroix может мыслями по этому поводу :-)

Вчера вечером у меня было немного свободного времени, и я попытался добавить GC.Collect() после вызова к Clear() в моем упрощенном воспроизведении. К сожалению, мне не удалось воспроизвести проблему таким образом.

Вы ждали ожидающих финализаторов?

Мы делаем это в наших тестах, чтобы быть уверенным
https://github.com/xamarin/Xamarin.Forms/blob/a76db1407a76fccbf487425db1bca5d15f925127/Xamarin.Forms.Controls.Issues/Xamarin.Forms.Controls.Issues.Shared/Helpers/GarbageCollectionHelpers/GarbageCollection

Это действительно хороший звонок. Но, к сожалению, даже после этого Clear() не запускает повторное воспроизведение.

Итак, сделаем шаг назад ... как это должно работать? Если привязка содержит слабую ссылку, то по определению этот объект может быть GC'd. Так что это может случиться, и XF не должен выдавать неуловимое исключение. Вместо этого ему, вероятно, следует просто игнорировать уведомление PropertyChanged и полагаться, что приложение знает, что делает. Я имею в виду, что еще он может делать?

Можете ли вы прикрепить репродукцию, которую используете, чтобы попытаться воссоздать?

Прикреплю код сегодня вечером. По сути, это уже знакомая вам копия внутри приложения, извлеченная в отдельное приложение. Но я еще не видел, чтобы в нем воспроизводилась проблема.

TypedBindingCrashes.zip

@PureWeen : что еще я могу сделать, чтобы помочь диагностировать это?

@mfeingol не сейчас, если у вас нет идей, как воспроизвести с помощью автономного приложения. Просто немного сложно сократить его в более крупном, поэтому мы будем немного медленнее с решением этого.

Возможно ли, что мы сможем продумать это концептуально, как я уже упоминал в https://github.com/xamarin/Xamarin.Forms/issues/6698#issuecomment -519359760? Или все еще не хватает сведений о том, что на самом деле вызывает проблему?

У меня такая же проблема, и я также не могу ее легко воспроизвести) -:

@ysmoradi : Я не думаю, что у вас есть возможность загрузить простую копию?

Это сложно воспроизвести даже в моем рабочем приложении!

У меня тоже есть репродукция, но, согласно @PureWeen, им сложно понять проблему без более простой репродукции. Я пытался, но не смог его создать. :-(

Я думаю, что было бы неплохо иметь имя свойства + имя типа представления + имя типа контекста привязки в сообщении об исключении, чтобы мы могли лучше понять.

У меня такая же проблема, iOS и Android, с использованием форм xamarin 4.2.0.709249.
У меня есть ListView, использующий DataTemplate для визуализации объектов, определенных в моем xaml.
У меня DataType установлен на странице xaml, а затем другой на табличке данных listview.

Мне не нужно вызывать clear или replace или что-либо в списке, к которому я привязан, кажется, достаточно вызвать GC.Collect и ожидать другого метода, чтобы выдать мне указанную выше ошибку. (Если у меня нет вызова GC.Collect, он дает сбой очень редко, но время от времени происходит, когда вызов загружается успешно, но не выполняется при обновлении.)

Однако я нашел кое-что интересное, если я удалю привязку между моим viewModel.IsBusy к listview.IsRefreshing, ошибка исчезнет (но, конечно, индикатор обновления продолжает работать после pull для обновления).

Кроме того, если я удалю тип данных на странице содержимого и установлю его только на табличке данных, ошибка также исчезнет, ​​и я могу использовать привязку к списку IsRefresing.

Подводя итог тому, что мне нужно в моем рабочем приложении для воспроизведения:

1. Установите DataType на ContentPage
2. Установить привязку для IsRefreshing в ListView
3. Сделайте вызов GC.Collect, за которым следует await Task.Delay (250); в методе, привязанном к списку RefreshCommand

@shoyheim : у вас есть простая репродукция, которую вы можете опубликовать здесь?

@shoyheim : у вас есть простая репродукция, которую вы можете опубликовать здесь?

@mfeingol Извините, я тестировал / отлаживал свой

@shoyheim : тебе когда-нибудь везло?

@mfeingol
Нет, извините, я пробовал, но всякий раз, когда я делаю простое воспроизведение, я не могу заставить его вылетать, но мое производственное приложение продолжает давать сбой и дает сбой.
Теперь я удалил все свои скомпилированные привязки и просто использую привязки времени выполнения в своих файлах xaml, и сбои исчезли.
Я потратил много времени, пытаясь выяснить, что идет не так, и единственное, в чем я уверен, это то, что существует связь между использованием ListView с привязкой к "isRefreshing", чтобы показать, когда список обновляется, и использованием скомпилированные привязки ... также кажется, что сбои происходят во время сборки мусора.

1- Свойство привязки контекста (модель представления) изменяется.
2- Мы открываем вид, чтобы он был уничтожен.
3- GC вызывается.

1. Вызывается Binding.Apply, и он пытается получить доступ к требуемым объектам, которые ушли, поэтому он выдает InvalidOperationException.
   Вы можете спросить, почему шаг 4 выполняется так поздно? Потому что он был вызван в Device.BeginInvokeOnMainThread, и такое действие будет добавлено в конец списка очереди действий основного потока.
   Я смог обработать это исключение, предоставив пользовательские PlatformServices для xf, и сбоев больше нет, но оно генерирует исключение более 800 раз! Практически для всех типизированных привязок уничтоженной страницы

@ysmoradi : Я потратил некоторое время, пытаясь воспроизвести ваши шаги, и мне не удалось вызвать сбой. Я не думаю, что у вас есть образец проекта.

Я уже говорил, что у меня нет простого репо, и это происходит в моем производственном приложении, и это также происходит случайным образом.
В первый раз, когда я начал создавать репо, я не знал многих вещей, но завтра я попробую создать еще один, используя свои новые предположения.
Еще один совет, который может помочь: исходя из моих предположений, одновременная активация сборки мусора приводит к увеличению шансов воспроизвести сбой. Потому что он может собирать объекты в отдельном потоке. Нам также необходимо изменить свойство модели представления для отдельного потока / задачи, поскольку Device.BeginInvokeOnMainThread передает действие в конец очереди основных потоков только тогда, когда оно вызывается в потоке, отличном от основного потока.
Попробуйте еще раз и дайте мне знать, если вы что-то нашли, и я попробую завтра.

У меня включен параллельный сборщик мусора. Используя ваши предложения, фрагмент кода, который я использую, делает следующее:

            Page1 page = new Page1();
            await this.Navigation.PushModalAsync(page);
            await Task.Run(() => { page.TXT = "Foo"; });
            await this.Navigation.PopModalAsync();

            GC.Collect();
            GC.WaitForPendingFinalizers();

            GC.Collect();
            GC.WaitForPendingFinalizers();

TXT - это свойство страницы Page1, реализованное с помощью BindableProperty. Страница 1 использует скомпилированные привязки.

По-прежнему не повезло.

Случайное получение такой же проблемы и в моем производственном приложении. Пройдя утомительный процесс установки x: Datatype повсюду в соответствии с рекомендациями по производительности, я не могу сказать, что я взволнован возможностью удалить их все из-за этой проблемы.

Я обновлю это с помощью приложения для воспроизведения, если мне удастся заставить его работать.

Примечание: я сомневаюсь, что это связано, но, похоже, я начал замечать проблему только после того, как начал использовать сжатые макеты. Вероятно, совпадение, поскольку проблема очень случайна, но кто знает.

Просто обновил мое приложение до MVVM со скомпилированными привязками и получил ту же ошибку.
Запуск последней версии Xamarin.Forms: 4.2.0.848062

Со следующей конфигурацией:

Также нет шагов по воспроизведению (эта версия приложения находится в бета-версии в течение дня, и у меня уже есть два отчета через AppCenter об этом).
Можно поделиться репозиторием приложений, но без шагов репро, я думаю, это не сильно поможет.

Возможно, я не понимаю всей картины, но не простое решение для этого - просто Отменить применение и вернуться, когда цель была собрана, как это уже происходит без определения DO_NOT_CHECK_FOR_BINDING_REUSE в TypedBinding.cs? Я не понимаю, насколько хорошо здесь бросать.

@fmanseau : Я того же мнения. @PureWeen?

Также, если это помогает, проблема, связанная с этим в репозитории Prism, похоже, имеет шаги воспроизведения (для этого требуется приложение Prism, но, вероятно, легко следовать аналогичному шаблону без него).

https://github.com/PrismLibrary/Prism/issues/1688

@StephaneDelcroix @ kingces95 @wachs
Вы, ребята, похоже, стоите за реализацией TypedBinding .

Как вы можете видеть в этой теме, у многих разработчиков (включая меня) время от времени происходит сбой приложения из-за ошибки InvalidOperationException вызванной TypedBinding .
Кажется, @samhouts прав в своем предположении, что после того, как target из TypedBinding (как это, скорее всего, имеет место в нашем приложении, где у нас довольно большой ListView со многими сложными DataTemplates ), TypedBinding выдает InvalidOperationException которое никогда не перехватывается и приводит к сбою приложения на Android (и, возможно, на любой другой платформе ??) как это:

TypedBinding 2[TSource,TProperty].Apply (System.Boolean fromTarget) System.InvalidOperationException: Operation is not valid due to the current state of the object. Stack traces TypedBinding 2 [TSource, TProperty] .Apply (System.Boolean fromTarget)
TypedBinding`2 + PropertyChangedProxy [TSource, TProperty].b__16_0 ()
Поток + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this)
(динамический метод оболочки) Android.Runtime.DynamicMethodNameCounter.43 (intptr, intptr)

Теперь @mfeingol разумно спрашивает, почему существует InvalidOperationException которое все- таки вызывает этот сбой. Я имею в виду, что концептуально не разрешалось собирать мусор для цели, зачем использовать слабую ссылку?

Я сам являюсь разработчиком WPF с .NET 3.0 и знаю, что исключения привязки никогда не вызывали сбоев, а только регистрировались.

Итак, мой вопрос:
Есть ли веская причина, по которой TypedBinding выдает исключение, а не просто игнорирует цель, если она была собрана?

Или, может быть, сама система привязки должна улавливать все исключения привязки и позволять нам, разработчикам, их проглатывать или реагировать соответствующим образом?

Это действительно важная ошибка для нашего производственного приложения, и при необходимости я бы создал для нас промежуточный выпуск Xamarin.Forms, который это исправляет. Но для этого я хочу знать, какие нежелательные эффекты это может иметь!

@bruzkovsky - это

Кроме того, @StephaneDelcroix @ kingces95 @wachs , я вижу флаг
DO_NOT_CHECK_FOR_BINDING_REUSE
Для чего это нужно?

Я бы очень хотел скомпилировать Xamarin.Forms с DO_NOT_CHECK_FOR_BINDING_REUSE установленным в true чтобы избавиться от этой ошибки.
Но какой мыслительный процесс стоит за этим? У этого флага должна быть веская причина, верно?

Это случилось со мной в простой ContentPage с ListView и DataTemplateSelector.
Есть ли обновления по этому поводу?
Почему в настоящее время рекомендуется использовать скомпилированные привязки, если эта проблема открыта?
https://docs.microsoft.com/es-es/xamarin/xamarin-forms/app-fundamentals/data-binding/compiled-bindings

@mrjavicho : есть ли шанс опубликовать простой проект, который последовательно воспроизводит проблему?

Мне удавалось часто воспроизводить проблему с этим образцом.
https://github.com/usausa/TypedBindingIssue

Запустите приложение и нажмите кнопку Test.
Кроме того, если вы удалите комментарий в MainPage.Cleanup (), проблема не возникнет.

Вот трассировка стека, которую я вижу с помощью кода @usausa . Не могу сказать, та же проблема, что и выше, но это определенно проблема:

    0x16 in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.Apply at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:99,5  C#  Annotated Frame
    0x7 in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.PropertyChangedProxy.<OnPropertyChanged>b__16_0 at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:277,31   C#  Annotated Frame
    0x29 in Xamarin.Forms.DispatcherExtensions.Dispatch at D:\a\1\s\Xamarin.Forms.Core\DispatcherExtensions.cs:53,6 C#  Annotated Frame
    0x3F in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.PropertyChangedProxy.OnPropertyChanged at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:277,5    C#  Annotated Frame
    0x15 in Xamarin.Forms.BindingExpression.WeakPropertyChangedProxy.OnPropertyChanged at D:\a\1\s\Xamarin.Forms.Core\BindingExpression.cs:645,6    C#  Annotated Frame
>   0x14 in TypedBindingIssueApp.NotificationObject.RaisePropertyChanged at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\NotificationObject.cs:13,13    C#  Symbols loaded.
    0x5D in TypedBindingIssueApp.LongLifecycleModel.Next at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\LongLifecycleModel.cs:19,13    C#  Symbols loaded.
    0x2A in TypedBindingIssueApp.MainPage.Button_OnClicked at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\MainPage.xaml.cs:29,17   C#  Symbols loaded.
    0x6 in System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1092,17   C#  Annotated Frame
    0x73 in System.Threading.ExecutionContext.RunInternal at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:968,17   C#  Annotated Frame
    0x4 in System.Threading.ExecutionContext.Run at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:910,13    C#  Annotated Frame
    0x32 in System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1073,25 C#  Annotated Frame
    0x6 in System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation.<>c.<.cctor>b__7_0 at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:379,78  C#  Annotated Frame
    0xC in Android.App.SyncContext. C#  Annotated Frame

Репро на высоте! Первое, что я заметил, это то, что сбой происходит в совершенно случайное время, иногда он нажимает кнопку несколько раз и ждет, поэтому я немного подправил его, чтобы сбой происходил раньше (последовательно после 29 сущностей):

Просто вызовите событие ПК 80 раз следующим образом:
c# for (var i = 0; i < 80; i++) RaisePropertyChanged(nameof(Entity));

Это планирует гораздо больше событий для диспетчера, что увеличивает частоту отказов.

При отключении компиляции XAML для классов View1 и View2 в BindingExpression.cs выдается NullReferenceException :

Все еще ищем простое решение ...