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 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.
I have a build file and bin directory for an app that crashes in the same place every time (in the run-time) and a second build log and bin directory for one that works just fine. All from the same, unchanged code base. The only difference between them is that I deleted the bin and obj directory of the APP project. If I give you the bin directory and the of the good and bad apps, will that work for you? I also have the build logs for each with -v -v -v.
Please request the URL to the location when you get to working on it, it's about 122MB and will be hosted on dropbox.
This sounds very much like #539 (which is a dup of #707).
Note that #707 doesn't necessarily require external (thumb) libraries, if the application is big enough you'll run into the same bug without any external libraries.
Note that the "application" includes a 68MB database and another 10MB of "other" and MDB files, the binary over 100MB, this is also compiled for debug.
I'm guessing compiled for release would reduce the likely hood of bad binaries?
This is becoming an bigger issue, we are relegated to working primarily in the simulator to get work done, but are attempting to do optimizations on the device.
What are the next steps?
The size problem is only with the main binary, not the entire .app directory, so resourecs, mdb files, etc do not count.
Anything that reduces the size of the main binary will reduce the probability of getting bad binaries (enabling the linker for instance). Splitting code into smaller, separate assemblies may also help (but it probably won't, since the problem is usually with mscorlib, which you can't split).
Enabling llvm while testing on device and only disable it when you need to debug (or use other debugging techniques, such as Console.WriteLines) is another workaround.
The comment about size was more related to the actual executable be 200 MB, it's 116MB I read it right, but that is still huge.
We've tried all the "experimental" build option, none provide a working binary, ever, for this application. Largely we only use the console debugging as it's the only thing that works consistently on the device.
Marking as a dup of #707 (which has been fixed, and the fix will be included in the 5.1.1 release).
If you can still reproduce the issue with 5.1.1 (after it has been released), then please reopen this bug.
*** This bug has been marked as a duplicate of bug 707 ***