Bug 2675 - MfA app deadlocks when paused in debugger
Summary: MfA app deadlocks when paused in debugger
Alias: None
Product: Android
Classification: Xamarin
Component: Debugger ()
Version: 4.0
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Zoltan Varga
Depends on:
Reported: 2011-12-28 17:34 UTC by Mikayla Hutchinson [MSFT]
Modified: 2013-12-05 18:34 UTC (History)
5 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 Mikayla Hutchinson [MSFT] 2011-12-28 17:34:33 UTC
If the default MfA app is running, and one pauses it in the debugger, then the IDE displays an empty stack, and nothing happens until one presses the button. At this point, the app suspends. This is expected because of how the soft debugger works.

However, there are serious problems:
1) The stack never updates to show where is managed code the app ended up stopping.
2) The app cannot be resumed or stepped. It is completely non responsive to user input or the deubgger, and has essentially deadlocked.
Comment 1 Jonathan Pryor 2013-05-23 14:50:28 UTC
Michael: Who owns this? Can it be repro'd on a Console app?
Comment 2 Mikayla Hutchinson [MSFT] 2013-05-23 15:46:15 UTC
Here's what happens:
1) user hits 'pause' in IDE
2) IDE sends 'pause' command to sdb agent inside app
3) sdb tries to suspend all threads
4) sdb is stuck waiting to suspend the mainloop thread because it's in javaland

At this point, the IDE has nothing to go on - it sent a command to sdb, but sdb didn't respond. It has no stack trace to display, and it won't send another command until sdb responds. And there's no way to recover except to bring up managed code on the mainloop by tapping a button or something.

I can't think of an easy fix, unfortunately. Perhaps we could display some "waiting for app to suspend" UI in the IDE, and modify sdb to allow the IDE to abort the pause command. Or maybe we could give sdb special awareness of the java mainloop, so it'll consider that to be suspended, and it it wakes up, suspend it on the java->managed transitions.

This is pretty much the same reason that "stop" doesn't work on the android debugger either.
Comment 3 Zoltan Varga 2013-05-23 16:39:58 UTC
This is not how things are supposed to work. sdb only suspends threads which are executing managed code, the others are only suspended if they enter/return to managed code. Even for these threads, it is possible to compute stack traces because some state is saved at the managed->native boundary.
Comment 4 Jonathan Pryor 2013-05-23 20:34:52 UTC
Zoltan: Would it be possible for sdb to suspend all suspendable threads and return a "wait-in-progress" message to the attached debugger, then suspend the unsuspendable threads as they enter managed code?

This would allow a more "immediate" experience to the developer, allowing them to at least inspect _some_ threads (e.g. the finalizer thread), and (somehow) have the IDE display non-suspended thread in a "special" manner (and in the ideal case, allow the IDE to tell the user how to suspend the thread, e.g. "click on a UI element that is handled in managed code").
Comment 5 Zoltan Varga 2013-05-23 20:44:29 UTC
sdb treats threads executing native code as suspended, so if the suspend request doesn't return pretty quickly, that is probably a bug.
Comment 6 Jonathan Pryor 2013-05-23 20:53:00 UTC
Zoltan: Ah. Well then we're probably seeing a bug. :-)

For example, Bug #10339: they start debugging an app, hit the stop button (which should kill the app), and then the app doesn't exit until ~10-20s later...on hardware (so not emulator overhead).

Our only current theory is that the 10-20s pause is because the IDE is waiting on sdb to "pause" all the threads before exiting the process, with the assumption that sdb was blocked waiting for an unmanaged thread to re-enter managed code. If sdb is in fact declaring threads executing native code as suspended, then this shouldn't be the case, and I thus have no idea why there's a 10-20s pause. :-(
Comment 7 Mikayla Hutchinson [MSFT] 2013-05-28 11:27:21 UTC
Yeah, I definitely see the behavior I describe - when I "pause" the app, nothing happens until I tap a button on the app. So it *looks* like the debugger is waiting for the main thread to hit managed code.
Comment 8 PJ 2013-11-19 17:04:41 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 9 PJ 2013-12-05 18:34:50 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.