Xamarin.forms: [Bug] InvalidOperationException em TypedBinding`2 [TSource, TProperty] .Apply

@mfeingol Se você puder restringir isso, pode anexar um pequeno projeto que demonstre esse problema? Obrigado!

Vou tentar fazer isso neste fim de semana, mas esse é meio difícil de reproduzir sob demanda. Alguma pista da sua parte, com base na sua compreensão do código?

Parece que isso está relacionado à vinculação XAML usando um DataType.

Estou viajando agora, mas minha solução temporária foi desativar as ligações compiladas.

@mfeingol Ok, parece certo. Se você tiver uma chance, forneça um projeto de amostra para nos ajudar a restringir o problema. Obrigado!

Estou vendo esse mesmo problema no iOS e no Android. Não estou usando ligações compiladas.

Problema do AppCenter:

TypedBinding 2[TSource,TProperty].Apply (System.Boolean fromTarget) TypedBinding 2 + PropertyChangedProxy [TSource, TProperty].b__16_0 ()
Thread + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this)
(método dinâmico do wrapper) System.Object.26 (intptr, intptr)

Projeto de formulários Xamarin, página Xaml com ViewModel - Grade contendo ScrollView - ScrollView contém rótulos. Bem simples.

@samhouts : Tentei o meu melhor, mas não consigo reproduzir o problema em um aplicativo de amostra. No entanto, tenho 100% de reprodução em meu aplicativo de produção.

Posso dar a alguém da sua equipe permissões para meu projeto do Azure DevOps para que eles possam reproduzir o problema?

shneuvil em microsoft.com

Você está em: https://dev.azure.com/sideroads/Sideroads

Etapas Repro:

1. git checkout 6698-repro e construir. Pode ser necessário adicionar o diretório externo à sua lista de diretórios NuGet para selecionar um pacote.
2. Execute o aplicativo e crie uma nova viagem na página de viagens. Nomeie a viagem com algo como "Teste" e deixe todos os padrões, exceto especificar partida e chegada e aeroportos (por exemplo, SEA e LAS).
3. Toque na viagem para selecioná-la.
4. No menu de hambúrguer, vá para a página do tempo, confirme se os boletins meteorológicos estão aparecendo para os locais relevantes.
5. Vá para as configurações, altere o provedor de clima de NWS para AQUI.
6. Volte para a página do tempo. Você deve ver uma falha muito rapidamente. Reiniciar o aplicativo deve reabrir na página de previsão do tempo, atualizar a previsão do tempo e gerar outra falha.

Se por algum motivo você não consegue reproduzir com uma viagem tão simples, exportarei uma mais sofisticada para você com mais locais.

@PureWeen : deixe-me saber se isso não está funcionando para você.

@mtirona :

@mfeingol Este problema está aparecendo aleatoriamente em nosso aplicativo. Não tenho um processo simples para recriar sob demanda - tenho centenas de travamentos no AppCenter documentando o problema. Eu ficaria muito grato por quaisquer instruções de como evitar o problema ...

@mtirona : você tem 100% de certeza de que não está usando x: DataType em nenhum lugar do seu XAML?

@mfeingol Havia x: DataType nas páginas pai, portanto,

Tenho cinco e nove anos de certeza de que isso está relacionado ao XamlC, a menos que você crie TypedBindings em seu próprio código (esses são _apenas_ criados pelo compilador Xaml)

Nota lateral: Estive no Xamarin Forms 3.6 e acabei de atualizar para o 4.1 mais recente. Na primeira execução do meu aplicativo, eu imediatamente vi essa falha enquanto adicionava itens rapidamente a uma página listview agrupada. Portanto, o problema ainda está presente no 4.1.0.618606.

@PureWeen : Eu atualizei as etapas de reprodução acima para fazer referência a um branch que você pode verificar e que deve reproduzir o problema imediatamente para você.

@mfeingol você pode fazer isso por mim?

Se por algum motivo você não consegue reproduzir com uma viagem tão simples, exportarei uma mais sofisticada para você com mais locais.

Eu tentei seus passos e nada travou para mim

Tudo bem, @mfeingol, não tenho certeza de como ou por que seus dados se alinham para causar esse problema, mas isso é o que eu sei até agora

O TypedBindings usa um WeakReference para o BindableObject, portanto, se for a única coisa que faz referência ao BindableObject, ele perderá essa referência.

Aqui está o código que falha
`` `C #
if (! _weakTarget.ExperimenteGetTarget (out target))
lance novo 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;

E se eu fizer isso, a falha não acontecerá.

Meu pensamento é que de alguma forma seus dados estão chegando a um lugar onde a única coisa que faz referência à instância de LocationDayWeatherViewModel que está ligada a ViewCell é TypeBinding e é isso. Ainda não descobri se isso é de alguma forma uma exceção do nosso lado em relação ao seu. Você pode ter certeza de que está mantendo uma referência para todos os LocationDayWeatherViewModel criados que estão vinculados ao ListView?

Obrigado por investigar isso! Esse problema tem sido muito difícil de reproduzir fora do aplicativo completo, então faz sentido que seja algo envolvendo referências fracas. Eu me pergunto se adicionar pressão de memória a uma reprodução mais simples pode resultar no mesmo problema.

De qualquer forma, a única vez em que uma instância de LocationDayWeatherViewModel não seria referenciada pelo modelo de visão seria durante uma atualização do dia do tempo, em que o código limpa o ObservableCollection vinculado de itens antes de inserir novos itens. Isso acontece no fundo de ExpandableGroupCollectionViewModel.Refresh no caso de você querer definir bps.

No entanto, eu acho que limpar um ObservableCollection vinculado deve ser uma operação segura, e não é óbvio para mim por que os vínculos XF estariam usando refs fracos. Parece que teria exatamente esse tipo de corrida.

À parte: tentei copiar os itens em this para uma lista temporária antes de limpar em Refresh , mas, surpreendentemente, isso não pareceu resolver o problema. Referenciei a lista no final do método para ter certeza de que o GC não o detonou também. Acho que isso faria sentido se o XF estivesse tentando usar a vinculação obsoleta "mais tarde" e sugeriria que não há uma boa maneira de um aplicativo estabilizar as referências vinculadas. Mas posso estar entendendo mal as coisas.

(E sim, o código de clima / expansor está um pouco fora de controle. Gostaria que o XF tivesse um controle Expander nativo ...)

Acho que adicionar pressão de memória ou apenas chamar GC.Collect pode recriar o problema em um projeto menor. Também pode acontecer porque OnPropertyChanged em TypedBinding é empacotado para o UI Thread

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

Então, com uma ideia clara, estou pensando no que pode estar acontecendo

PropertyChanged queue'd no UI Thread
Claro
GC
WeakReference perde a referência
PropertyChanged agora resolve e lança uma exceção

Talvez esteja relacionado a esse problema?
https://github.com/xamarin/xamarin-android/issues/2049

@StephaneDelcroix pode ter alguns insights adicionais neste ponto :-)

Tive um pouco de tempo livre ontem à noite e tentei adicionar GC.Collect() após a chamada para Clear() em meu repro simplificado. Infelizmente, não consegui reproduzir o problema dessa forma.

Você esperou pelos finalizadores pendentes?

Fazemos assim em nossos testes apenas para ter certeza
https://github.com/xamarin/Xamarin.Forms/blob/a76db1407a76fccbf487425db1bca5d15f925127/Xamarin.Forms.Controls.Issues/Xamarin.Forms.Controls.Issues.Shared/Helpers#/GarbageCollection9

Essa é uma decisão muito boa. Mas, infelizmente, mesmo depois disso, Clear() não aciona uma reprodução.

Então, dando um passo para trás ... como isso deve funcionar? Se uma ligação está mantendo uma referência fraca, então, por definição, esse objeto pode ser GC'd. Então, isso é algo que, bem, pode acontecer, e o XF não deveria lançar uma exceção não capturável. Em vez disso, ele provavelmente deve simplesmente ignorar a notificação PropertyChanged e confiar que o aplicativo sabe o que está fazendo. Quer dizer, o que mais ele pode fazer?

Você pode anexar o repro que está usando para tentar recriar?

Vou anexar o código esta noite. É basicamente a reprodução no aplicativo que você já viu, extraída em um aplicativo independente. Mas ainda não vi o problema se reproduzir dentro dele.

TypedBindingCrashes.zip

@PureWeen : mais alguma coisa que posso fazer para ajudar a diagnosticar isso?

@mfeingol não agora, a menos que você tenha alguma ideia de como reproduzir com o aplicativo independente. É um pouco complicado reduzi-lo no maior, então vamos um pouco mais devagar para resolver este.

É possível que possamos pensar nisso conceitualmente, como mencionei em https://github.com/xamarin/Xamarin.Forms/issues/6698#issuecomment -519359760? Ou ainda faltam peças sobre o que está realmente causando o problema?

Tenho o mesmo problema e também não consigo reproduzi-lo facilmente) -:

@ysmoradi : Suponho que você não consiga fazer upload de uma reprodução simples.

É difícil reproduzir mesmo no meu aplicativo de produção!

Eu também tenho uma reprodução em produção, mas de acordo com @PureWeen , é difícil para eles entenderem o problema sem uma reprodução mais simples. Eu tentei e falhei em produzir um. :-(

Eu acho que é uma boa ideia ter o nome da propriedade + nome do tipo de visualização + nome do tipo do contexto de ligação na mensagem da exceção, para que possamos ter melhores insights.

Estou tendo exatamente o mesmo problema, iOS e Android, usando os formulários xamarin 4.2.0.709249.
Eu tenho um ListView usando um DataTemplate para visualizar os objetos, definidos no meu xaml.
Eu tenho DataType definido na página xaml e, em seguida, um diferente no datatemplate listview.

Não preciso chamar clear ou replace ou anyting na lista à qual estou vinculando, parece ser suficiente chamar GC.Collect e aguardar outro método para me dar o erro acima. (Se eu não tenho a chamada GC.Collect, ele falha muito raramente, mas falha de vez em quando, com a chamada ele carrega com sucesso, mas falha na atualização.)

No entanto, eu encontrei algo interessante, se eu remover minha ligação entre meu viewModel.IsBusy e listview.IsRefreshing o erro vai embora, (mas o indicador de atualização continua em execução após puxar para atualizar, é claro).

Além disso, se eu remover o tipo de dados na página de conteúdo e configurá-lo apenas no datatemplate, o erro também desaparecerá e posso usar a vinculação no listview IsRefresing.

Para resumir o que preciso ter em meu aplicativo de produção para reproduzir:

1. Definir DataType na ContentPage
2. Definir vinculação em IsRefreshing em ListView
3. Ter uma chamada GC.Collect seguida por await Task.Delay (250); no método ligado ao listview RefreshCommand

@shoyheim : você tem uma reprodução simples para postar aqui?

@shoyheim : você tem uma reprodução simples para postar aqui?

@mfeingol Desculpe, tenho testado / depurado meu código de produção. Vou ver se consigo apertar algum tempo para fazer algo que reproduza o erro ...

@shoyheim : você já teve sorte com isso?

@mfeingol
Não, desculpe, eu tentei, mas sempre que faço uma reprodução simples, não consigo travar, mas meu aplicativo de produção continua travando e travando.
Agora eu removi todos os meus vínculos compilados e apenas usei vínculos em tempo de execução em meus arquivos xaml, e os travamentos desapareceram.
Passei muito tempo tentando descobrir o que está errado, e a única coisa que tenho certeza é que há uma conexão entre o uso de ListView com uma ligação em "isRefreshing" para mostrar quando a lista está sendo atualizada e o uso de vinculações compiladas ... também parece que os travamentos acontecem na época da coleta de lixo.

1- Uma propriedade do contexto de ligação (modelo de visualização) é alterada.
2- Abrimos a visualização para que seja destruída.
3- GC é chamado.

1. Binding.Apply é chamado e tenta obter os objetos necessários de acesso que se foram, então lança InvalidOperationException.
   Você pode perguntar por que a etapa 4 é executada tão tarde? Porque ele foi chamado em Device.BeginInvokeOnMainThread, e tal ação será adicionada ao final da lista da fila de ações do thread principal.
   Consegui lidar com essa exceção fornecendo PlatformServices personalizados para xf e não há mais travamento, mas ele lança uma exceção mais de 800 vezes! Para quase todas as encadernações digitadas de páginas destruídas

@ysmoradi : Passei algum tempo tentando reproduzir seus passos e não consegui acionar nenhum travamento. Suponho que você não tenha um projeto de amostra.

Eu disse antes que não tenho nenhum repo simples e isso está acontecendo no meu aplicativo de produção e também acontece aleatoriamente.
Na primeira vez que comecei a criar um repo, não estava ciente de muitas coisas, mas amanhã tentarei criar outro usando minhas novas suposições.
Outras dicas que podem ajudar: Com base em minhas suposições, ter resultados habilitados para GC simultâneo aumenta a chance de reproduzir o travamento. Porque ele pode coletar objetos em um thread separado. Também precisamos mudar a propriedade de um modelo de visão em um thread / tarefa separado porque Device.BeginInvokeOnMainThread passa a ação para o final da fila de threads principais apenas quando é chamada em um thread diferente do thread principal.
Tente novamente e me avise se você encontrar algo, e tentarei amanhã.

Eu tenho o GC simultâneo ativado. Usando suas sugestões, o snippet de código que estou usando faz o seguinte:

            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 é uma propriedade na Página1, implementada usando uma BindableProperty. Página1 está usando ligações compiladas.

Ainda sem sorte.

Obtendo o mesmo problema aleatoriamente aqui também no meu aplicativo de produção. Depois de passar pelo processo tedioso de definir x: Datatype em todos os lugares, conforme recomendado nas diretrizes de desempenho, não posso dizer que estou feliz por ter que remover todos eles por causa desse problema.

Vou atualizar isso com um aplicativo de reprodução, se conseguir fazer um funcionar.

Observação: duvido que isso esteja relacionado, mas parece que só comecei a ver o problema depois que também comecei a usar layouts compactados. Provavelmente uma coincidência já que o problema é muito aleatório, mas quem sabe.

Acabei de atualizar meu aplicativo para MVVM com ligações compiladas e obtendo o mesmo erro agora.
Executando o Xamarin.Forms mais recente: 4.2.0.848062

Com a seguinte configuração:

Também não tenho etapas de reprodução (esta versão do aplicativo está em beta por um dia e eu já tenho dois relatórios via AppCenter sobre isso).
Pode compartilhar o repositório do aplicativo, mas sem as etapas de reprodução, acho que não ajudaria muito.

Posso não estar entendendo o quadro todo, mas a solução fácil para isso não é simplesmente cancelar a aplicação e retornar quando o destino foi GCed, como já é o caso sem o DO_NOT_CHECK_FOR_BINDING_REUSE definido em TypedBinding.cs? Não vejo como jogar é uma boa ideia aqui.

@fmanseau : Eu tenho a mesma opinião. @PureWeen?

Além disso, se ajudar, um problema relacionado a isso no repo do Prism parece ter etapas de repro (ele requer um aplicativo Prism, mas provavelmente é fácil seguir um padrão semelhante sem ele).

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

@StephaneDelcroix @ kingces95 @wachs
Vocês parecem estar por trás da implementação TypedBinding .

Como você pode ver neste tópico, muitos desenvolvedores por aí (incluindo eu) têm seu aplicativo travando de vez em quando por causa de um InvalidOperationException lançado pelo TypedBinding .
Parece que @samhouts está certa em sua suposição, que após o GC ação e remover o target de um TypedBinding (como é muito provável o caso em nosso aplicativo, onde temos um ListView com muitos DataTemplates complexos), o TypedBinding lança um InvalidOperationException que nunca é detectado e leva a uma falha do aplicativo no Android (e potencialmente em qualquer outra plataforma ??) como isso:

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 ()
Thread + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this)
(método dinâmico do wrapper) Android.Runtime.DynamicMethodNameCounter.43 (intptr, intptr)

Agora @mfeingol pergunta razoavelmente porque existe um InvalidOperationException que causa esta falha afinal. Quer dizer, conceitualmente não era permitido ter o destino coletado como lixo, por que usar uma referência fraca?

Eu mesmo sou um desenvolvedor WPF desde .NET 3.0 e sei que as exceções de ligação nunca causaram uma falha, mas apenas foram registradas.

Então minha pergunta:
Existe algum bom motivo pelo qual TypedBinding lança uma exceção e não apenas ignora o destino se ele foi coletado?

Ou talvez o próprio sistema de vinculação deva capturar todas as exceções de vinculação e permitir que os desenvolvedores as engulam ou reajam de forma adequada?

Este é realmente um bug importante para nosso aplicativo de produção e se necessário, eu criaria uma versão intermediária do Xamarin.Forms para nós que corrige isso. Mas para isso eu quero saber que efeitos indesejáveis ​​isso pode ter!

@bruzkovsky - isso pode ser do seu interesse também

Além disso, @StephaneDelcroix @ kingces95 @wachs , posso ver um sinalizador
DO_NOT_CHECK_FOR_BINDING_REUSE
Para que serve exatamente?

Eu gostaria muito de compilar o Xamarin.Forms com DO_NOT_CHECK_FOR_BINDING_REUSE definido como true para me livrar desse bug.
Mas qual é o processo de pensamento por trás disso? Deve haver um bom motivo para ter esta bandeira presente, certo?

Isso acabou de acontecer comigo em um ContentPage simples com um ListView e DataTemplateSelector.
Existe alguma atualização sobre este problema?
Como é que atualmente é recomendado usar ligações compiladas se esse problema estiver aberto?
https://docs.microsoft.com/es-es/xamarin/xamarin-forms/app-fundamentals/data-binding/compiled-bindings

@mrjavicho : alguma chance de você postar um projeto simples que reproduza o problema de forma consistente?

Consegui reproduzir o problema frequentemente com este exemplo.
https://github.com/usausa/TypedBindingIssue

Execute o aplicativo e clique no botão Testar.
Além disso, se você remover o comentário em MainPage.Cleanup (), o problema não ocorrerá.

Aqui está o rastreamento de pilha que estou vendo usando o código de @usausa . Não posso dizer se é o mesmo problema acima, mas é definitivamente um problema:

    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

A reprodução está no local! A primeira coisa que notei foi que a falha ocorre em momentos completamente aleatórios, às vezes pressionando o botão várias vezes e esperando, então eu ajustei um pouco para fazê-la falhar mais cedo (consistentemente após 29 entidades):

Apenas acione o evento PC 80 vezes assim:
c# for (var i = 0; i < 80; i++) RaisePropertyChanged(nameof(Entity));

Isso agenda muito mais eventos para o despachante, o que aumenta a taxa de falha.

Ao desativar a compilação XAML para as classes View1 e View2 , há um NullReferenceException lançado em BindingExpression.cs:

Ainda procurando uma solução simples ...