Forum Xamarin.Forms
We are excited to announce that the Xamarin Forums are moving to the new Microsoft Q&A experience. Q&A is the home for technical questions and answers at across all products at Microsoft now including Xamarin!

We encourage you to head over to Microsoft Q&A for .NET for posting new questions and get involved today.

random crashes with thread dumps

It's a peculiar bug, this one. I can't reproduce it consistently but it happens too often to just be a coincidence.

When does it happen:
It always happens when I attempt to navigate and allthough there is some random factor to it, it appears to happen mostly when I navigate from my Main login page to the dashboard (the first page users see after logging in)

What happens:
The application simply stops dead in its tracks and no longer responds to inputs, allthough no ANR popup is shown (even after waiting for over a minute). There's also no exception in the output that I can see. Just some strange thread dump.

03-30 11:38:48.433 D/Mono (20585): Assembly Ref addref Xamarin.Forms.Platform.Android[0xb4b200a0] -> Xamarin.Android.Support.v7.AppCompat[0xb4b0de80]: 2 STATE CUE CARD: (? means a positive number, usually 1 or 2) 0x0 - starting (GOOD, unless the thread is running managed code) 0x1 - running (BAD, unless it's the gc thread) 0x2 - detached (GOOD, unless the thread is running managed code) 0x?03 - async suspended (GOOD) 0x?04 - self suspended (GOOD) 0x?05 - async suspend requested (BAD) 0x?06 - self suspend requested (BAD) 0x07 - blocking (GOOD) 0x?08 - blocking with pending suspend (GOOD) --thread 0x8d42cb80 id 0x93f96d00 [0x5187] state 1 GC INITIATOR --thread 0xaec49d80 id 0x99ab9580 [0x50a8] state 1 --thread 0x9b0d8700 id 0x9b2f5c80 [0x5087] state 1 --thread 0xaec45080 id 0x9b2f6400 [0x5085] state 1 --thread 0xaec45e80 id 0x9b2f7080 [0x5088] state 1 --thread 0x9b0d5600 id 0x9cbc1f00 [0x5084] state 1 --thread 0xaec46c80 id 0xaec77d00 [0x50a0] state 1 --thread 0x999f3080 id 0xaec79b00 [0x50a4] state 1 --thread 0xaec4ab80 id 0xaec7af00 [0x50b0] state 1 --thread 0xb499aa80 id 0xb4929400 [0x507e] state 1 --thread 0xaec44280 id 0xb492968 0 [0x507f] state 1 --thread 0xb499a700 id 0xb6fc8bec [0x5069] state 103 WAITING for 1 threads, got 0 suspended 03-30 11:38:48.987 F/ (20585): suspend_thread suspend took 264 ms, which is more than the allowed 200 ms

Googling did not yield any interesting results. Any idea why this happens?


  • bump

  • bump²

  • might want to add it happens on Android only (so far at least) and on the "PopToRoot" method.

  • `public async Task SetAndPopToRoot() where TViewModel : class, IViewModel
    if (_isNavigating)

            _isNavigating = true;
            TViewModel viewModel;
            Debug.WriteLine("resolving new root");
            var newRoot = _viewFactory.Resolve<TViewModel>(out viewModel);
            Debug.WriteLine("retrieving old root from stack");
            var oldRoot = Navigation.NavigationStack.FirstOrDefault();
            //var newRoot = _viewFactory.Resolve(viewModel);
            Debug.WriteLine("disabling navigationbars on new root");
            NavigationPage.SetHasNavigationBar(newRoot, false);
            Debug.WriteLine("inserting page in navigationstack");
            Navigation.InsertPageBefore(newRoot, oldRoot);
            Debug.WriteLine("closing menus");
            Debug.WriteLine("popping to new root");
            //await Navigation.PopToRootAsync(animated);
            //possible workaround for thread crashing on popToRoot
            if (Navigation.NavigationStack.Count > 2)
                await Navigation.PopToRootAsync();
                await Navigation.PopAsync();
            Debug.WriteLine("broadcasting navigation event");
            _isNavigating = false;

    this is the code (with some debug loggin and an attempted workaround).

    It basically replaces the current rootpage of the application (to keep people from using the back key to go somewhere they're not supposed to go).

  • zebra-brzebra-br USUniversity ✭✭

    Seeing the same suspend_thread error in an app. Did you have any luck tracking this down?

  • i'm afraid not. It kinda just stopped happening after a xamarin update

Sign In or Register to comment.