Bug 57648 - Debugger breaking on null object
Summary: Debugger breaking on null object
Alias: None
Product: Runtime
Classification: Mono
Component: Debugger (show other bugs)
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: Future Cycle (TBD)
Assignee: Zoltan Varga
Depends on:
Reported: 2017-06-20 22:03 UTC by James Clancey
Modified: 2017-10-20 15:16 UTC (History)
6 users (show)

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

Test Case (3.71 MB, application/zip)
2017-10-17 00:40 UTC, James Clancey

Description James Clancey 2017-06-20 22:03:02 UTC
I am getting a null object crash in my app. I think it might be my bug but it is impossible to track down.  When the null object exceptions occurs, the debugger pauses but the call stack is empty. Also none of my code files are opened or highlighted when the exception occurs.  If I am on the latest alpha, I get no stack trace during the crash.  If I am on stable I get a native crash:


This is 100% reproducible in my Xamarin.Mac app

If you clone https://github.com/Clancey/gMusic/tree/bass

run the setup.sh which will clone the dependencies.

You can now debug the Mac app.

Start playing any song that has to stream, while it is playing the app will crash as soon as the download completes. It only happens if the current downloading song is the current song.
Comment 1 James Clancey 2017-06-20 22:13:18 UTC
Also here is the crash in insights. No data: https://www.dropbox.com/s/lyn4vljrjlq26kc/Screenshot%202017-06-20%2014.10.19.png?dl=0
Comment 2 David Karlaš 2017-06-21 12:59:29 UTC
Looks like runtime crash, hence reassigning
Comment 3 Zoltan Varga 2017-06-21 18:47:15 UTC
I have trouble compiling the app, Setup.sh fails with:

'SQLitePCLRaw.bundle_green' already has a dependency defined for 'SQLitePCLRaw.core'.
'SQLitePCLRaw.core' already has a dependency defined for 'NETStandard.Library'.
Comment 4 James Clancey 2017-06-21 19:20:02 UTC
Updated nuget, try again please.
Comment 5 Zoltan Varga 2017-06-21 22:37:08 UTC
For history, this is caused by mono 5ed682646f07b3bd59c888a00e8b5d120c968d53, so we
throw an exception from ftnptr_eh_callback_default () using mono_raise_exception (), but that
function is called from native-to-managed wrappers without a wrapper, so the debugger
cannot do a stack walk.
Comment 6 James Clancey 2017-10-13 21:57:36 UTC
Any update?
Comment 7 James Clancey 2017-10-17 00:40:57 UTC
Created attachment 25325 [details]
Test Case
Comment 8 Zoltan Varga 2017-10-19 12:07:33 UTC
Comment 9 Zoltan Varga 2017-10-19 14:18:33 UTC
As a workaround, try setting an exception catchpoint on Exception, that will stop the app when the exception is thrown. By default, VS4M only seems to catch uncaught exceptions, and by the time the runtime realizes the exception is uncaught, there are no more managed frames left to display.
Comment 10 Zoltan Varga 2017-10-20 15:16:37 UTC

Note You need to log in before you can comment on or make changes to this bug.