Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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 for Bug 57648 on
GitHub or Developer Community if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
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.
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
Looks like runtime crash, hence reassigning
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'.
Updated nuget, try again please.
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.
Created attachment 25325 [details]
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.