Bug 3357 - 5.2 Stack traces don't include file name/line number when running without debugging
Summary: 5.2 Stack traces don't include file name/line number when running without deb...
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: 5.2
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Rolf Bjarne Kvinge [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2012-02-10 06:39 UTC by David N. Junod
Modified: 2015-10-21 18:23 UTC (History)
6 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:
VERIFIED FIXED

Description David N. Junod 2012-02-10 06:39:07 UTC
Since upgrading to 5.2, when I get an exception in Debug it no longer includes the filename and line number in the stack trace.  This is true for both the Simulator and Device.

2012-02-10 03:32:32|MT0|System.NullReferenceException: Object reference not set to an instance of an object
  at wtkJams.VenueController.<OnServiceRemoved>m__2B () [0x00000] in <filename unknown>:0 
  at MonoTouch.Foundation.NSActionDispatcher.Apply () [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00000] in <filename unknown>:0 
  at wtkJams.Application.Main (System.String[] args) [0x00000] in <filename unknown>:0
Comment 1 Rolf Bjarne Kvinge [MSFT] 2012-02-10 07:29:33 UTC
This works fine for me on a simple test project - are you sure you have debugging enabled in the project's options? Does it also happen if you try with a new project from a template?
Comment 2 David N. Junod 2012-02-10 07:44:21 UTC
All I did was upgrade to 5.2.  Yes, Debugging is enabled in the project's options.  I've tried switching it off & on, no effect.

I just created a new Utility application.  Same thing.

Unhandled Exception: System.DivideByZeroException: Division by zero
  at NewProject.AppDelegate.FinishedLaunching (MonoTouch.UIKit.UIApplication app, MonoTouch.Foundation.NSDictionary options) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00000] in <filename unknown>:0 
  at NewProject.Application.Main (System.String[] args) [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.DivideByZeroException: Division by zero
  at NewProject.AppDelegate.FinishedLaunching (MonoTouch.UIKit.UIApplication app, MonoTouch.Foundation.NSDictionary options) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) MonoTouch.UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
  at MonoTouch.UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00000] in <filename unknown>:0 
  at NewProject.Application.Main (System.String[] args) [0x00000] in <filename unknown>:0
Comment 3 Rolf Bjarne Kvinge [MSFT] 2012-02-10 08:13:12 UTC
Are you debugging the application or only running it without debugging?
Comment 4 David N. Junod 2012-02-10 08:16:04 UTC
I've always done "Run".  Prior to 5.2, it would show filename and line number in a stack trace.
Comment 5 Rolf Bjarne Kvinge [MSFT] 2012-02-10 08:19:21 UTC
OK, I can reproduce this now.

Zoltan: would you happen to know why file name / line numbers don't show up when running without attaching the debugger?
Comment 6 Zoltan Varga 2012-02-10 08:39:57 UTC
Does the app binary includes the mdb files ?
Comment 7 Zoltan Varga 2012-02-10 08:45:07 UTC
Also, the aot images need to be compiled with --debug, and without the 'nodebug' aot option, otherwise they won't include the debug information need to produce line numbers in stack traces.
Comment 8 David N. Junod 2012-02-10 08:47:34 UTC
All I did was upgrade to 5.2.  I didn't make any changes to the project settings.

And, it is already set to --debug.
Comment 9 Rolf Bjarne Kvinge [MSFT] 2012-02-10 08:48:21 UTC
Sorry, it's in the simulator (haven't tried device yet). When running with debugging in MD, the file names and line numbers show up (so the mdb files are there).
Comment 10 guivho 2012-02-20 12:37:09 UTC
I am not sure it is to be blamed upon 5.2 but I'm running 5.2 and I got
this same problem.

I can easily reproduce it with following steps:

* Create a new single view monotouch solution.

* Add following code before the 'return true;' in the FinishedLaunching
  method in the AppDelegate.cs source:

            try {
                throw new Exception();
            } catch ( Exception e) {
                Console.WriteLine(e.StackTrace);
            }

* Run the app in Debug Mode, and it barks:

  at StackTraceTest.AppDelegate.FinishedLaunching
  (MonoTouch.UIKit.UIApplication app, MonoTouch.Foundation.NSDictionary
  options) [0x00000] in <filename unknown>:0

It is definitely not a Mono runtime problem. It works fine in a Mono
asp.net application, in a simple console project, etc...

The link to 5.2 may be correct. This feature definitely did work in the
past, unfortunately I didn't observe nor register when exactly it
stopped working.

I use this stacktrace info whenever I'm debugging. Rather than stepping
through the source, I usually insert calls to my P(...) method at
strategic places. It takes a varying number of objects and prints their
string representation preceded by 'MyFileName.cs:MyMethod(241)' or
whatever. It's difficult that this no longer shows filename nor linenr.

At least it still prints the method name. The latter is surprising, I
assume it also has to be retrieved from the mdb file.

Needless to say that all mdb files used in the project are contained in
the bin/Debug directory.

So please investigate.

(Very willing to provide any additional info you might require)

Guido
Comment 11 guivho 2012-02-20 12:42:49 UTC
I forgot to mention that this error does occur when running the app, it
does work when debugging it.

And indeed it did work before when just running the app in the
'Debug|iPhoneSimulator' configuration, one did not need to debug it to
get at filename and linenr info.


Guido
Comment 12 David N. Junod 2012-02-20 12:47:11 UTC
I see the same thing in MonoMac now too.

If I do Debug of a Debug app, it shows all the information, but if I do Run of a Debug app, it only shows the method information not the filename or line number.
Comment 13 Mikayla Hutchinson [MSFT] 2012-02-21 15:14:19 UTC
David, that's by design. Mono only loads debug information when the app is run in debug mode, regardless of how the app was built.
Comment 14 Rolf Bjarne Kvinge [MSFT] 2012-02-21 19:23:34 UTC
IMHO the debug configuration exists to provide as much debugging information as possible, so I think this should be changed then.
Comment 15 David N. Junod 2012-02-21 19:27:45 UTC
Unless I have a terrible memory, this worked fine up until I upgraded to 5.2  Debug is Debug, regardless of how you run it.  If it is by design, then it is a new design and not industry standard at all.
Comment 16 David N. Junod 2012-02-21 19:31:02 UTC
No, I don't have a terrible memory.  This used to work fine pre-5.2.  I looked into my old crash logs from the field.

2012-01-22 08:45:29	ME0	
System.Xml.XmlException: Text node cannot appear in this state.  Line 1, position 1.
  at Mono.Xml2.XmlTextReader.ReadText (Boolean notWhitespace) [0x00199] in /Developer/MonoTouch/Source/mono/mcs/class/System.XML/System.Xml/XmlTextReader.cs:1704 
  at Mono.Xml2.XmlTextReader.ReadContent () [0x0015c] in /Developer/MonoTouch/Source/mono/mcs/class/System.XML/System.Xml/XmlTextReader.cs:1346 
  at Mono.Xml2.XmlTextReader.Read () [0x00141] in /Developer/MonoTouch/Source/mono/mcs/class/System.XML/System.Xml/XmlTextReader.cs:620 
  at System.Xml.XmlTextReader.Read () [0x0006b] in /Developer/MonoTouch/Source/mono/mcs/class/System.XML/System.Xml/XmlTextReader2.cs:564 
  at wtkJams.XmlPropertyList.parse (System.String content) [0x001d0] in /Users/djunod2/Developer/Android/RealityCheckInc/gitrepo/kJams/mono/kJamsApp/kJamsApp/Common/XmlProperty
Comment 17 Rolf Bjarne Kvinge [MSFT] 2012-02-21 19:42:42 UTC
I can confirm it broke somewhere between 5.1.1 and 5.1.2.
Comment 18 Mikayla Hutchinson [MSFT] 2012-02-21 20:35:21 UTC
I was talking about MonoMac apps. When we run the app from MD, we run it as an bundle via the OS app launch APIs, so we can't pass options such as --debug directly to Mono. Of course, we could modify the launcher code in the apps built in debug configurations to pass that option to Mono, but that should be a separate bug, since it's not related to MonoTouch.
Comment 19 Rolf Bjarne Kvinge [MSFT] 2012-02-22 07:02:02 UTC
Fixed in 351a0dab (master) and 3cb90b93 (5.2-series).

It will be included in the next 5.2 release (5.2.6).
Comment 20 PJ 2012-02-29 12:18:59 UTC
Verified as fixed on 5.2.6. 

On Mac Lion
MD 2.8.8.0 RC6
Mono 2.10.9
Comment 21 Joseph Hanna 2015-10-20 22:40:44 UTC
This is still a problem for me.  I get crash reports from production applications and I have NO idea where to find the "Null reference exception" because there is no filename nor line number.

XS 5.9.7 (build 22) on Mac 10.11
Mono 4.0.4
Xamarin.iOS 9.0.1.29


System.NullReferenceException: Object reference not set to an instance of an object
  at AcmeInc.FieldSales.SearchController.LoadSearchResults (System.String title, Boolean showHistoryQuantities, AcmeInc.FieldSales.Customer customer, AcmeInc.FieldSales.ListingEventArgs e) [0x00000] in <filename unknown>:0 
  at AcmeInc.FieldSales.SearchController..ctor (ListingTypeEnum listingType, UIKit.UIViewController host, System.String keywordString, System.String title, System.Collections.Generic.List`1 lps, Boolean showHistoryQuantities, AcmeInc.FieldSales.Customer customer, AcmeInc.FieldSales.ListingEventArgs e) [0x00000] in <filename unknown>:0 
  at AcmeInc.FieldSales.SearchController.ShowModal (UIKit.UIViewController host, System.String title, System.String keywordString, System.Collections.Generic.List`1 lps, ListingTypeEnum listingType, AcmeInc.FieldSales.Customer customer, Boolean showHistoryQuantities) [0x00000] in <filename unknown>:0 
  at AcmeInc.FieldSales.OrderEntry.StartSearch () [0x00000] in <filename unknown>:0 
  at AcmeInc.FieldSales.OrderEntry.HandleSearchOrderEntryhandleSearchButtonClicked (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0 
  at UIKit.UISearchBar+_UISearchBarDelegate.SearchButtonClicked (UIKit.UISearchBar searchBar) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
  at UIKit.UIApplication.Main (System.String[] args, IntPtr principal, IntPtr delegate) [0x00000] in <filename unknown>:0 
  at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00000] in <filename unknown>:0 
  at FieldSales.Application.Main (System.String[] args) [0x00000] in <filename unknown>:0 ____________________________________________________________
Stack:
System.NullReferenceException: Object reference not set to an instance of an object
  at AcmeInc.FieldSales.SearchController.LoadSearchResults (System.String title, Boolean showHistoryQuantities, AcmeInc.FieldSales.Customer customer, AcmeInc.FieldSales.ListingEventArgs e) [0x00000] in <filename unknown>:0 
  at AcmeInc.FieldSales.SearchController..ctor (ListingTypeEnum listingType, UIKit.UIViewController host, System.String keywordString, System.String title, System.Collections.Generic.List`1 lps, Boolean showHistoryQuantities, AcmeInc.FieldSales.Customer customer, AcmeInc.FieldSales.ListingEventArgs e) [0x00000] in <filename unknown>:0 
  at AcmeInc.FieldSales.SearchController.ShowModal (UIKit.UIViewController host, System.String title, System.String keywordString, System.Collections.Generic.List`1 lps, ListingTypeEnum listingType, AcmeInc.FieldSales.Customer customer, Boolean showHistoryQuantities) [0x00000] in <filename unknown>:0 
  at AcmeInc.FieldSales.OrderEntry.StartSearch () [0x00000] in <filename unknown>:0 
  at AcmeInc.FieldSales.OrderEntry.HandleSearchOrderEntryhandleSearchButtonClicked (System.Object sender, System.EventArgs e) [0x00000] in <filename unknown>:0 
  at UIKit.UISearchBar+_UISearchBarDelegate.SearchButtonClicked (UIKit.UISearchBar searchBar) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) UIKit.UIApplication:UIApplicationMain (int,string[],intptr,intptr)
  at UIKit.UIApplication.Main (System.String[] args, IntPtr principal, IntPtr delegate) [0x00000] in <filename unknown>:0 
  at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) [0x00000] in <filename unknown>:0 
  at FieldSales.Application.Main (System.String[] args) [0x00000] in <filename unknown>:0 ____________________________________________________________
Comment 22 Rolf Bjarne Kvinge [MSFT] 2015-10-21 07:52:15 UTC
@Joseph, that's technically not a crash report, but a managed exception. Managed exceptions will not have file names / line numbers unless the .mdb files are packaged with the app, which is disabled for release builds (it significantly increases app size). You can override this by adding "--package-mdb" to the additional mtouch arguments in the project's iOS Build options. Alternatively you can let the app crash (IOW not handle the exception in your code), and look at the resulting crash report (which can be symbolicated locally or by crash reporting services to provide stack frames with file name / line number information).
Comment 23 Joseph Hanna 2015-10-21 18:23:24 UTC
Thanks @Rolf.