**

Ogłoszenie; 21-12-2018 - zmieniono nazwę pytania, aby była zgodna z nową instancją tego problemu. Informacje na ten temat znajdują się na dole.

**

Od 3 tygodni zmagam się z tym błędem, próbowałem wszystkiego, co przyszło mi do głowy, nawet przeinstalowałem Visual Studio 2017.

Najpierw trochę historii;

Tworzę aplikację, w której można zamawiać kanapki i większość ważnych funkcji jest skończona. Cały proces zamawiania działa już od 4 miesięcy. Kilka tygodni temu miał miejsce tydzień katastrofy, przepalona skrzynka bezpieczników, która spowodowała awarię zasilania. To w jakiś sposób złamało zaporę i zepsuła się cała sieć firmowa. Podczas instalacji studia android (wraz z visual studio/xamarin). Kilka dni później aktualizacja Visual Studio 2017 poszła nie tak, a ja całkowicie przeinstalowałem i usunąłem Android Studio. Potem zaczęły się pojawiać błędy.

Większość aplikacji nadal działa dobrze, jednak możesz się zalogować, sprawdzić koszyki, przeglądać kategorie itp.; po wywołaniu określonej funkcji w implementacji REST aplikacja wyłącza się, a debuger pokazuje błąd Fatal signal 6 SIGABRT -6.

12-07 12:57:29.409 F/ (20795): * Potwierdzenie w /Users/builder/jenkins/workspace/xamarin-android-d15-9/xamarin-android/external/mono/mono/mini/unwind.c: 640, warunek `cfa_reg != -1' nie jest spełniony

12-07 12:57:29.409 F/libc (20795): Fatal signal 6 (SIGABRT), kod -6 w numerze 20828 (Thread Pool Wor), pid 20795 (np. nazwa aplikacji)

Kod poniżej:

public async Task<ObservableCollection<T>> GetAllWithId<T>(Guid id)
{
    var t = typeof(T);
    var uri = GetURI<T>();
    ObservableCollection<T> oc = new ObservableCollection<T>();
    try
    {
        var tmpUri = "";
        // IF statements to determine URI, if no ifs succeed let run and catch exception.. ps. can be changed for typeswitch
        if (typeof(T) == typeof(Product)) { tmpUri = uri + "/incategory/" + id; }/*use category id inside*/
        if (typeof(T) == typeof(Order)) { tmpUri = uri + "/fromuser/" + id; }/*use user id*/
        var client = GetNewClient();
        using (client)
        {
            HttpResponseMessage result = await client.GetAsync(tmpUri);
            if (result.IsSuccessStatusCode)
            {
                var content = await result.Content.ReadAsStringAsync();
                Debug.WriteLine(content);             
                oc = JsonConvert.DeserializeObject<ObservableCollection<T>>(content);// <<<<<< SIGABRT THROWN HERE
                //* Assertion at /Users/builder/jenkins/workspace/xamarin-android-d15-9/xamarin-android/external/mono/mono/mini/unwind.c:640, condition `cfa_reg != -1' not met
            }
        }
    }
    catch (Exception ex)
    {
        Debug.WriteLine(@"ERROR {0}", ex.Message);
    }

    return oc;
}

Jest jedna implementacja używająca generyków używanych przez wszystkie kontrolery. Metody getURI i getNewClient odpowiednio kompilują identyfikator URI do odpowiedniego typu i zwracają instancję klienta.

Od początku rozwoju, rdzeń xamarin i inne pakiety nie były aktualizowane, ponieważ zwykle powoduje to uszkodzenie. Aktualne wersje wszystkich pakietów są takie same, jak na początku rozwoju (tj. kiedy nie było błędów). (lista pakietów i wersji na dole).

Błąd występuje w ostatnich 2 wersjach pakietów newtonsoft.json (błąd zaczął się w wersji 11.0.2, potem zaktualizowałem do wersji 12.0.1, błąd nadal występuje). Dane API są pobierane i działają zgodnie z przeznaczeniem i zwracają dane w odpowiednim formacie. Debuger nie pokazuje śladu stosu, ale mówi, że błąd jest zwykle spowodowany przez natywny kod mono lub kod natywny używany przez zależności.

Jeśli ktoś potrzebuje więcej informacji, chętnie je udzielę, ponieważ nie mogłem znaleźć niczego w google, jak to naprawić.

Błąd występuje również na wszystkich emulatorach (od 512 MB do 2 GB pamięci RAM, różne rozmiary sterty i różne renderery. Nie mogę przetestować na fizycznym urządzeniu, ponieważ sieć jest nadal zablokowana i jakoś urządzenie nie może się połączyć)

VersionInformation

Aktualizacja; jest naprawiony (chyba). 20-12-2018

Ja jawnie buduję obiekty po stronie API i wysyłam je jako obiekt odpowiedniego typu (np. Produkt, Zamówienie itp.) zamiast var.

Po deserializacji, reserializacji i powtórzeniu tego jeszcze raz uzyskałem działające, ale rażąco nieefektywne rozwiązanie.

Następnie wyciąłem kilka niestandardowych getterów i seterów we właściwościach modeli. (Nie jest to w żadnym wypadku wskazana przyczyna tego problemu, ale pomogło to naprawić).

To nadal działało, następnie próbowałem użyć oryginalnej linii kodu, jak pokazano w pytaniu, co zadziałało.

Uwaga, dwukrotnie ponownie zainstalowałem Visual Studio (raz podczas aktualizacji z 15.9.2 do 15.9.3, a wczoraj odinstalowałem i zainstalowałem z nową aktualizacją 15.9.4).

Odbywa się to na starszej gałęzi, która nadal ma oryginalne wersje wszystkich zależności.

Podsumowując, ten błąd nie powinien być spowodowany błędami w niedopasowanych obiektach deserializacji. Taki błąd powinien być zgłaszany jako błąd deserializacji lub coś podobnego, a nie natywny błąd rozwijania mono.

(Wiersz kodu, który powoduje ten błąd, jest otoczony przez dwa zagnieżdżone bloki try-catch..)

Aktualizacja... to się powtórzyło 21-12-2018

Więc błąd zniknął wczoraj. Miałem nadzieję, że to na dobre, ale teraz to się powtórzyło. Zawęziłem to do modelu produktu. (ponieważ pierwotny błąd wystąpił podczas wczytywania produktów i podczas wczytywania zamówień historycznych, które tylko współdzieliły tę samą metodę API, musiał tam być i też był).

Wyrzucany jest ten sam błąd, tyle że teraz historyczne zamówienia nadal działają, z wyjątkiem produktów, które nie. Stało się tak, gdy dodałem niestandardowy getter i setter do mojego modelu. kod poniżej;

public Object ProductImage {
             get { return ProductImage; }
             set {

                try
                {
                    if (value.ToString().Contains("/api/DynamicImages/getimageonly/"))
                    {
                        string imreBase64Data = Convert.ToBase64String(Constants.ObjectToByteArray(value));
                        ProductImage = string.Format("data:image/png;base64,{0}", imreBase64Data);
                    }
                    else
                    {
                        ProductImage = value;
                    }


                }
                catch (Exception ex) { ProductImage = value; }


            }
           //   get;set;//<-- when i use this instead no signal abort is thrown but the images wont load when they are retrieved as either a file or data from my own API. (images retrieved as link to external site still work, falling back to place holders still works too.)
        }

Kiedy wracam do prostego get;set; to działa. Czy są chętni? Uwaga; Zaktualizowałem nazwę pytania, aby była bardziej konkretna dla tego nowego wydania.

0
Daan 7 grudzień 2018, 15:22

1 odpowiedź

Najlepsza odpowiedź

Główną przyczyną jest ciągłe wywołanie rekurencyjne.
takich jak:
ProductImage = wartość -> ponownie uruchomi ustawiacz połączeń.
w rezultacie seter jest wywoływany raz za razem.

W javie zgłosi błąd przepełnienia stosu w takim przypadku.
jednak w mono pokazuje taki komunikat o błędzie, który nie jest jasny dla debugowania.

Rozwiązaniem jest:

private Object _productImage;
public Object ProductImage {
    get { return _productImage; }
    set {
    ... 
    _productImage = {some value};
    }
}
0
user2767141 15 maj 2019, 16:07