Bug 1992 - Two builds, same code, different results for device, works fine with simulator
Summary: Two builds, same code, different results for device, works fine with simulator
Status: RESOLVED DUPLICATE of bug 707
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: 5.0
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2011-11-10 10:55 UTC by kenny goers
Modified: 2011-11-29 07:45 UTC (History)
3 users (show)

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:

Description kenny goers 2011-11-10 10:55:37 UTC
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.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2011-11-11 04:18:53 UTC
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.
Comment 4 kenny goers 2011-11-11 08:07:15 UTC
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?
Comment 5 Rolf Bjarne Kvinge [MSFT] 2011-11-11 08:19:32 UTC
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.
Comment 6 kenny goers 2011-11-11 08:29:43 UTC
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.
Comment 7 Rolf Bjarne Kvinge [MSFT] 2011-11-29 07:45:05 UTC
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 ***