Bug 11938 - Step In doesn't step but hangs debugging often when debugging Xam.Mac application
Summary: Step In doesn't step but hangs debugging often when debugging Xam.Mac applica...
Status: RESOLVED FIXED
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Zoltan Varga
URL:
Depends on:
Blocks:
 
Reported: 2013-04-24 12:33 UTC by Chris Hamons
Modified: 2013-07-26 14:26 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Stack Trace (53.29 KB, text/plain)
2013-04-24 12:33 UTC, Chris Hamons
Details
The real logs (229.90 KB, application/zip)
2013-04-26 12:43 UTC, Chris Hamons
Details


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 FIXED

Description Chris Hamons 2013-04-24 12:33:42 UTC
Created attachment 3866 [details]
Stack Trace

While at a breakpoint, I attempt to step in. Instead of stepping in, my debugging session going into a state where I'm no longer at a breakpoint but the app i'm debugging is still hung. 

I followed the steps here (http://monodevelop.com/Developers/Reporting_Bugs#Debugging_Hangs_on_Mac_and_Linux) and have attached the gdb stack. The Kill command didn't output anything resembling a stack.

I can reproduce this often, so feel free to ask for more information.
Comment 1 Zoltan Varga 2013-04-24 13:21:19 UTC
How can I reproduce this ?
Comment 3 Chris Hamons 2013-04-24 13:26:30 UTC
The source code base I'm working on is 93 projects and thousands of files so I can't send my current steps to reproduce.

Is there a way I can send a stack trace with symbols or something that'd be useful? 

One other interesting thing to note is if the thing I'm stepping into has a breakpoint at some point, we'll skip directly to that breakpoint when I step in (unless that thing is a property getter/setter).
Comment 4 Chris Hamons 2013-04-24 13:27:00 UTC
I don't have a log in for that website so I can't check.
Comment 5 Zoltan Varga 2013-04-24 14:45:17 UTC
Is the problem reproducible ? I.e. does it always happen when stepping from a specific location in the code ?
Comment 6 Chris Hamons 2013-04-24 14:47:32 UTC
We hit it enough times around here that the general advice is that "don't use step in, it doesn't work".

Once I find a spot where step in freaks out, I can restart the debug session and reproduce the behavior over and over.
Comment 7 Zoltan Varga 2013-04-24 14:51:39 UTC
Could you paste the code around the spot you are trying to step in, plus the start of the method you are trying to step into ? Also, what version of xamarin.mac is this ?
Comment 9 Zoltan Varga 2013-04-24 15:19:38 UTC
Do the other places where stepping fails are inside iterators as well, or the problem happens inside normal methods as well ?
Comment 10 Zoltan Varga 2013-04-24 15:23:25 UTC
Is 'Step over properties and operators' enabled in Preferences/Debugger ? Does turning it off fix this problem ?
Comment 11 Chris Hamons 2013-04-24 16:11:50 UTC
It was turned on, and turning it off didn't fix my issue, but it did make me think of something. In this example:

    class Foo 
    {
        internal Bar B
        {
            get
            {
                return new Bar();
            }
        }
    }

    class Bar
    {
        internal void Buzz()
        {
            Console.WriteLine("Buzz");
        }
    }

    class MainClass
    {
        public static void Main(string[] args)
        {
            Foo f = new Foo();
            f.B.Buzz();
        }
    }
}

Set a breakpoint on the console line and the f.B.Buzz();

If you have step over set, and step into the f.B.Buzz(), you will skip your Console breakpoint and jump to the next line.
Comment 12 Zoltan Varga 2013-04-24 16:23:45 UTC
Yes, that is a known problem, I tought that it might be the cause of this bug too, apparently, its not.
Comment 13 Zoltan Varga 2013-04-24 19:02:00 UTC
Could you run xamarin studio from the command line like this:
MONO_SDB_ENV_OPTIONS=loglevel=10 "/Applications/Xamarin Studio.app/Contents/MacOS/XamarinStudio"

When debugging a xamarin.mac app in this xamarin studio instance, the application output pane should contain lots of debug information. Could you run the app until the breakpoint, save the contents of the output pane into a log file, step in once, then save the contents into another log file, and attach both files ?
Comment 15 Zoltan Varga 2013-04-26 12:16:27 UTC
That didn't work out, the output should include logging messages from the runtime. Are you sure you set
the environment variable 'MONO_SDB_ENV_OPTIONS' to 'loglevel=10' before starting xamarin studio from the command line ?
Comment 16 Chris Hamons 2013-04-26 12:43:42 UTC
Created attachment 3881 [details]
The real logs
Comment 17 Zoltan Varga 2013-04-26 18:55:27 UTC
The BeforeStep.txt file looks ok, however the AfterStep.txt file seems truncated at the beginning, it is missing the logging for the beginning of the single step operation. I found an easier method, try
setting MONO_SDB_ENV_OPTIONS to: "loglevel=10,logfile=$HOME/log". This way, the log messages will go to the file $HOME/log, so there is no need to copy them.
Comment 19 Zoltan Varga 2013-04-29 12:35:49 UTC
From the log, it looks like the 'Step over properties and operators' option is still turned on. There is a known bug where using this option could slow down debugging to the point that the program appears to hang.  Could you re-run the test with this option turned off ?
Comment 21 Zoltan Varga 2013-04-30 08:38:46 UTC
The issue with stepping over properties will be fixed in our mono 3.0 based release, however, the changes required were too complex to backport to the current mono 2.10 based release.
Comment 22 Miguel de Icaza [MSFT] 2013-07-26 14:26:45 UTC
This should be fixed with the new release