Bug 36207 - Under unknown conditions, when VS debugger hits breakpoint, Android app crashes.
Summary: Under unknown conditions, when VS debugger hits breakpoint, Android app crashes.
Status: RESOLVED NOT_REPRODUCIBLE
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger ()
Version: 4.2.0 (C6)
Hardware: PC Windows
: --- blocker
Target Milestone: ---
Assignee: Zoltan Varga
URL:
Depends on:
Blocks:
 
Reported: 2015-11-24 09:52 UTC by philip
Modified: 2017-07-08 03:15 UTC (History)
11 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 GitHub or Developer Community 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 NOT_REPRODUCIBLE

Description philip 2015-11-24 09:52:23 UTC
# Steps to reproduce

Not sure, but this seems to be related to debugging async methods.
1. Debug Android App
2. wait for breakpoint to hit inside nested async methods inside PCL project
3. breakpoint hits, but after about 1 second the debugger disconnects and app crashes, making debugging impossible.
4. If I insert "await Task.Delay(5000);" before the breakpoint everything is OK until after breakpoint hits.  This proves that the problem is not the code but XF VS related.

11-24 09:43:58.219 E/mono-rt ( 5694): Stacktrace:
11-24 09:43:58.219 E/mono-rt ( 5694): 
11-24 09:43:58.219 E/mono-rt ( 5694): 
11-24 09:43:58.219 E/mono-rt ( 5694): Attempting native Android stacktrace:
11-24 09:43:58.219 E/mono-rt ( 5694): 
11-24 09:43:58.220 E/mono-rt ( 5694):  at ???+0 [0xb2566e76]
11-24 09:43:58.220 E/mono-rt ( 5694):  at ???+0 [0xb25673a4]
11-24 09:43:58.220 E/mono-rt ( 5694):  at ???+0 [0xb25673a4]
11-24 09:43:58.220 E/mono-rt ( 5694):  at ???+0 [0xb25673a4]
11-24 09:43:58.220 E/mono-rt ( 5694):  at ???+0 [0xb2575d10]
11-24 09:43:58.220 E/mono-rt ( 5694):  at ???+0 [0xb26bf4b4]
11-24 09:43:58.220 E/mono-rt ( 5694):  at _ZL15__pthread_startPv+56 [0xb7509168]
11-24 09:43:58.220 E/mono-rt ( 5694):  at __start_thread+25 [0xb7503c69]
11-24 09:43:58.220 E/mono-rt ( 5694):  at __bionic_clone+70 [0xb74fa7c6]
11-24 09:43:58.220 E/mono-rt ( 5694): 
11-24 09:43:58.220 E/mono-rt ( 5694): =================================================================
11-24 09:43:58.220 E/mono-rt ( 5694): Got a SIGSEGV while executing native code. This usually indicates
11-24 09:43:58.220 E/mono-rt ( 5694): a fatal error in the mono runtime or one of the native libraries 
11-24 09:43:58.220 E/mono-rt ( 5694): used by your application.
11-24 09:43:58.220 E/mono-rt ( 5694): =================================================================
11-24 09:43:58.220 E/mono-rt ( 5694): 
11-24 09:43:58.220 F/libc    ( 5694): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xc2edd046 in tid 5713 (Thread-343)
Mono.Debugger.Soft.VMDisconnectedException: Exception of type 'Mono.Debugger.Soft.VMDisconnectedException' was thrown.
   at Mono.Debugger.Soft.Connection.SendReceive(CommandSet command_set, Int32 command, PacketWriter packet)
   at Mono.Debugger.Soft.Connection.Object_GetValues(Int64 id, Int64[] fields)
   at Mono.Debugger.Soft.ObjectMirror.GetValues(IList`1 fields)
   at Mono.Debugger.Soft.ObjectMirror.GetValue(FieldInfoMirror field)
   at Mono.Debugging.Soft.FieldValueReference.get_Value()
   at Mono.Debugging.Evaluation.ValueReference.GetValue(EvaluationContext ctx)
   at Mono.Debugging.Evaluation.ValueReference.OnCreateObjectValue(EvaluationOptions options)
   at Mono.Debugging.Evaluation.ValueReference.CreateObjectValue(EvaluationOptions options)

# Expected behavior

When halted at breakpoint, debugger should not disconnect

# Actual behavior

debugger disconnects and app crashes

# Supplemental info (logs, images, videos)

Please don't ask for a sample app.  I won't have time to try to create one.

# Test environment (full version information)
VS2015, Win 10, Android 5.1
Comment 1 philip 2015-11-24 09:55:15 UTC
To clarify:  Breakpoints work in non-async functions and even some async functions.  Some breakpoints always work (non-async always seems to work) while others always cause debugger disconnection (async but not all async methods).
Comment 2 Chase 2015-11-24 10:43:41 UTC
@philip I've noticed in our iOS app that breakpoints don't work properly if the first breakpoint is outside of the container project (AppDelegate).  By hitting a breakpoint in the UI project first, subsequent breakpoints start working.  Just something to try.
Comment 3 philip 2015-11-24 10:57:06 UTC
This does not help and the breakpoints actually all work.  But after the breakpoint hits, the debug connection is closed and the application crashes.
Comment 4 Joaquin Jares 2015-11-26 09:11:39 UTC
This looks like a runtime bug. Assigning to runtime for investigation. Please revert back to us if it isn't.
Comment 5 Rodrigo Kumpera 2015-11-27 17:56:59 UTC
Hey guys,

Could one of you provide some guidance on how to reproduce this issue?

From your comments this is how much information I have:

- It happens to do with some async methods.
- The disconnect happens once the breakpoint on those problematic async method are hit.

phillip, can you attach the full logcat output a bad debugging session? That might provide us with more actionable information.

Another important thing is if you have a method that consistently crashes every time. Just sharing that method would be a good start for us.
Comment 6 philip 2015-12-16 16:09:56 UTC
We can close this bug for now.  I changed my code to work around the issue and now I can no longer reproduce it so perhaps the latest update fixes it?
Comment 7 Jeroen 2016-01-05 12:31:37 UTC
I get the described behavior when setting a breakpoint on an await statement, and continuing execution upon hitting the breakpoint. Could looks like this:


      private async Task<T> GetAsync<T>(String requestUri)
      {
         // create the client
         using (var client = new HttpClient())
         {
            // set defaults
            ...

            // make the call
            HttpResponseMessage response = await client.GetAsync(requestUri);

            // if succesful
            if (response.IsSuccessStatusCode)
            {
Comment 8 philip 2017-04-10 16:32:06 UTC
this is an old bug, so probably best to close it
Comment 9 Ludovic Henry 2017-07-08 03:15:08 UTC
Can you still reproduce with latest mono? If that's the case, please feel free to reopen. Thank you.