Bug 322 - USB debugging requires the process to terminate on the remote side.
Summary: USB debugging requires the process to terminate on the remote side.
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Debugger ()
Version: 4.x
Hardware: PC Linux
: --- normal
Target Milestone: Untriaged
Assignee: Rolf Bjarne Kvinge [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2011-08-18 09:54 UTC by Miguel de Icaza [MSFT]
Modified: 2011-12-02 06:29 UTC (History)
4 users (show)

Tags:
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:
Status:
RESOLVED FIXED

Description Miguel de Icaza [MSFT] 2011-08-18 09:54:30 UTC
The new MonOTouch 4.1 support for USB debugging has the unfortunate side effect of requiring the developer to start the application twice since the first time he resets the application, he gets a "Socket address already in use" or something like that.

Toshok believes that this is because the app is still running on the client.  There are a few possible solutions:

* The debugger always kills the target process when the program is reset, or

* Have the connection be made from the debugged program to MonoDevelop, instead of the other way around.
Comment 1 Mikayla Hutchinson [MSFT] 2011-08-18 19:28:12 UTC
The debugger does kill the process when the debugging session is terminated.

My guess would be that when the user "quits" the app on the device, it gets suspended, which prevents MD communicating with it. MD would unexpectedly lose its connection to the debugging session and assume the app has crashed. Even if the connection is not lost but simply hangs, MD would be unable to terminate the app. When the app is "started" (i.e. resumed), it discovers its debugger connection has been lost, and crashes.

This means that starting the app would still work correctly if the user terminated the app from MD instead of pressing the home button on the device.

The only way to handle this is if MD can terminate suspended processes on the device, or if the app terminates as soon as it's suspended. The latter option is more viable but would prevent debugging suspended/resumed apps, however it sounds like that doesn't work anyway.
Comment 2 Mikayla Hutchinson [MSFT] 2011-09-02 09:51:58 UTC
Verified, this isn't actually a bug in USB debugging, it's the suspend problem. It affects simulator too.
Comment 3 Rolf Bjarne Kvinge [MSFT] 2011-09-07 06:55:35 UTC
I committed a fix that should help a bit, we weren't closing the socket we used to listen for connections from MonoDevelop in most cases.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2011-09-07 18:05:45 UTC
One thing that might mitigate this is if the app is killed on the device if the user hits the stop button in the IDE. Currently nothing happens at all.

Manually killing the app on the device has some strange issues with "socket already in use" errors. It depends entirely on the sequence things are done, following no apparent logic (note that in all cases I'm restarting an already killed app, so the socket shouldn't be in use anymore):

== Sequence 1 ==
start debugging in MD & start app
suspend app
kill app
(MD stops debugging automatically)
restart app -> socket already in use
=> fail

== Sequence 2 ==
start debugging in MD & start app
suspend app
hit stop button in MD
kill app
restart app -> socket already in use
=> fail

== Sequence 3 ==
start debugging in MD & start app
hit stop button in MD
suspend & kill app (it doesn't die by itself)
restart debugging in MD
start app
=> ok
Comment 5 Mikayla Hutchinson [MSFT] 2011-09-07 19:03:47 UTC
I'm pretty sure hitting the stop button in MD while an app is being debugged terminates the app.
Comment 6 Rolf Bjarne Kvinge [MSFT] 2011-09-08 05:10:33 UTC
I just checked it, and it tries to terminate the app, but the app isn't killed until I click something.

I tracked it down to sdb trying to suspend all threads in the process before shutting down, but the main thread is not running managed code so it won't be suspended immediately (which is why it exits when I click on something - it starts running managed code, the thread is suspended, exit sequence continues and finally the process is shut down).
Comment 7 Rolf Bjarne Kvinge [MSFT] 2011-09-08 05:11:00 UTC
CC'ing Zoltan due to sdb issue (see last comment).
Comment 8 Zoltan Varga 2011-09-08 10:22:09 UTC
sdb treats threads not running managed code as suspended, they will be really suspended when they enter managed code again. At least this is how it is supposed to work.
Comment 9 Rolf Bjarne Kvinge [MSFT] 2011-09-08 16:58:28 UTC
sdb calls mono_thread_suspend_all_other_threads, which sends a signal to each thread and eventually the thread will end up in mono_thread_request_interruption, which has this comment:

/* Can't stop while in unmanaged code. Increase the global interruption
    request count. When exiting the unmanaged method the count will be
    checked and the thread will be interrupted. */

(and that code path is the one entered too)
Comment 10 Zoltan Varga 2011-09-08 19:08:22 UTC
That code is the same code executed when somebody calls Environment.Exit ().
Comment 11 Rolf Bjarne Kvinge [MSFT] 2011-09-09 11:00:56 UTC
That doesn't change the fact that the app stays open when the user hits Stop in MD :)

But why do we do a clean shutdown in the first place? Can't we just call exit?
Comment 12 Rolf Bjarne Kvinge [MSFT] 2011-10-24 17:24:47 UTC
This should work a bit better now, I've changed MT to set SO_REUSEADDR on the listening socket.

There is still the issue of having to manually kill the app on the device, I have a patch for that (which goes together with the profiler changes), leaving bug open until that has been fixed too.
Comment 13 Rolf Bjarne Kvinge [MSFT] 2011-12-02 06:29:28 UTC
Debugging should work a lot better as of MT 5.1.1 and MD 2.8.5