Bug 3548 - Wrong stack trace is displayed
Summary: Wrong stack trace is displayed
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Debugger ()
Version: unspecified
Hardware: PC Linux
: Normal normal
Target Milestone: ---
Assignee: Jeffrey Stedfast
URL:
Depends on:
Blocks:
 
Reported: 2012-02-20 09:09 UTC by Marek Safar
Modified: 2013-04-01 17:34 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 Marek Safar 2012-02-20 09:09:49 UTC
using System;
using System.Collections.Generic;
using System.Text;
using System.Diagnostics;
using System.Reflection;

class C
{
	public static void Main ()
	{
		var all = typeof (C).Assembly.GetReferencedAssemblies (); // Set a breakpoint here and do few 2 Step intos
		all[0].CultureInfo.NumberFormat = null;
		return;
	}
}

With enabled framework debugging observe the stack trace

Actual stack trace does not make much sense

System.Version..ctor (major=4, minor=0, build=0, revision=0)
System.Reflection.MonoAssembly.GetReferencedAssemblies ()
C.Main ()
Comment 1 Zoltan Varga 2012-02-21 11:41:27 UTC
GetReferencedAssemblies () is an icall which calls Version:.ctor () from native code.
Comment 2 Marek Safar 2012-02-21 12:12:19 UTC
GetReferencedAssemblies() is not icall

GetReferencedAssemblies (Assembly module) is icall

So, I'd expect the stack to be at least

System.Version..ctor (major=4, minor=0, build=0, revision=0)
System.Reflection.MonoAssembly.GetReferencedAssemblies (Assembly module)
System.Reflection.MonoAssembly.GetReferencedAssemblies ()
C.Main ()

Ideally something like

System.Version..ctor (major=4, minor=0, build=0, revision=0)
<unmanaged code>
System.Reflection.MonoAssembly.GetReferencedAssemblies (Assembly module)
System.Reflection.MonoAssembly.GetReferencedAssemblies ()
C.Main ()
Comment 3 Zoltan Varga 2012-02-23 07:17:19 UTC
Support for this has been implemented in sdb. Frames for icalls/pinvokes are now returned if the ThreadMirror.NativeTransitions static property is set. These frames have their IsNativeTransition property set. Their associated method is an icall/pinvoke method.

Icalls doesn't seem to have associated line number info, so md can't display their source location.

-> md.
Comment 4 Marek Safar 2012-02-23 08:03:57 UTC
I know that "extern" methods don't have line info because there is no IL to link it with. Any idea how to workaround it
Comment 5 Marek Safar 2012-03-20 07:37:36 UTC
Jeff, any progress on this one ?
Comment 6 Jeffrey Stedfast 2012-10-19 17:53:17 UTC
is this the same as bug #3062?
Comment 7 Marek Safar 2012-10-22 03:53:14 UTC
Jeff, no
Comment 8 Jeffrey Stedfast 2013-04-01 15:17:37 UTC
we seem to display every frame that the runtime gives us, so I dunno what I have to do to fix this if there's even anything to fix on MD's side.
Comment 9 Mikayla Hutchinson [MSFT] 2013-04-01 16:08:35 UTC
Well, we need to check that XS sets ThreadMirror.NativeTransitions, and that it displays the frames sanely when debugging a version of the runtime that has zoltan's fixes.
Comment 10 Jeffrey Stedfast 2013-04-01 17:34:55 UTC
fixed in git master