Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
Michael: Who owns this? Can it be repro'd on a Console app?
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.
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.
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").
sdb treats threads executing native code as suspended, so if the suspend request doesn't return pretty quickly, that is probably a bug.
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. :-(
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.
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.
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.