Bug 12164 - Debugging on Device causes malloc_error_break until build->clean and rebuild
Summary: Debugging on Device causes malloc_error_break until build->clean and rebuild
Status: RESOLVED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: Debugger (show other bugs)
Version: 6.3.x
Hardware: PC Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Rolf Bjarne Kvinge [MSFT]
URL:
Depends on:
Blocks:
 
Reported: 2013-05-08 09:09 UTC by Redth
Modified: 2013-06-21 09:30 UTC (History)
5 users (show)

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


Attachments
Crash Report (95.31 KB, application/octet-stream)
2013-05-08 13:43 UTC, Redth
Details


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:
RESOLVED FIXED

Description Redth 2013-05-08 09:09:23 UTC
Running the latest alpha (Version: 6.3.4.36 (Business Edition)) on device (iPhone 4S, iOS 6.1.3), I get an error every time I go to build after changing some code and running on device (doesn't seem to happen in simulator).  The only thing that fixes it is to Build->Clean and then build/run again, then it works fine.

Here's the error:

Please ensure your device is connected...
Connected to: Jonathan's iPhone
Launching /private/var/mobile/Applications/F1C83A9C-1E71-44E5-A774-13CA47C0524E/MonoTouchSample.app -debugtrack -monodevelop-port 10000 -connection-mode usb
ZxingSharpMonoTouchSample(241,0x3b5fdb88) malloc: *** mmap(size=2147487744) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
Comment 1 Chris Hardy [MSFT] 2013-05-08 10:00:52 UTC
I see the same issue using the following sample too https://www.dropbox.com/s/xwpxmo14aktllu0/SimpleCollectionViewCrash.zip

with the following 'random' crashes: https://gist.github.com/chrisntr/fb4b40c10760d511306d
and
https://gist.github.com/chrisntr/e9e8dfa694e406e6c36c

even though the value "Kind" is not null.
Comment 2 Rolf Bjarne Kvinge [MSFT] 2013-05-08 10:23:20 UTC
Redth, can you attach a crash report?
Comment 3 Rolf Bjarne Kvinge [MSFT] 2013-05-08 10:24:19 UTC
Zoltan, ChrisNTR's report here: https://gist.github.com/chrisntr/fb4b40c10760d511306d indicates a problem related to debug and/or aot, can you try to reproduce? I wasn't able to on any of my devices.
Comment 4 Zoltan Varga 2013-05-08 11:56:16 UTC
I can't reproduce it by starting that app in debug mode. Can somebody upload the actual .app dir for the app which has this problem ?
Comment 5 Chris Hardy [MSFT] 2013-05-08 12:14:26 UTC
Zotan, I believe the app sample that I uploaded has the .app file in there and it fails for me but worked fine for Rolf too :/
Comment 6 Zoltan Varga 2013-05-08 13:24:20 UTC
I cannot reproduce it with the binaries for that sample.
Comment 7 Redth 2013-05-08 13:43:59 UTC
Created attachment 3935 [details]
Crash Report
Comment 8 Redth 2013-05-08 13:46:42 UTC
Here's the actual .app that just caused this for me right now:

https://www.dropbox.com/sh/3hkydxopae0dgrl/-KeN2ofEmQ
Comment 9 Zoltan Varga 2013-05-08 17:16:15 UTC
Does this happen in debug or in release mode ? If its release mode, could you enable the 'Enable debugging' option in project options/iOS Build, so the executable has debugging info ?
Comment 10 Zoltan Varga 2013-05-08 17:50:35 UTC
This could be caused by the AOT image caching stuff. Is there a way to turn that off ?
Comment 11 Rolf Bjarne Kvinge [MSFT] 2013-05-08 17:55:53 UTC
Add -f to the additional mtouch arguments to always force a recompile.
Comment 12 Chris Hardy [MSFT] 2013-05-09 14:46:20 UTC
Adding in -f seems to fix the problem, let me try and get you that info Zoltan for Release mode.
Comment 13 Chris Hardy [MSFT] 2013-05-09 14:54:34 UTC
Here's the release crash - not sure if you need anything else: https://gist.github.com/chrisntr/f107e5f0ce9cef56d673
Comment 14 Zoltan Varga 2013-05-09 16:01:02 UTC
That seems to be a completely unrelated problem, its not a crash, but an unhandled exception.
Comment 15 Chris Hardy [MSFT] 2013-05-09 16:05:29 UTC
The crash is from the following line:             

CollectionView.RegisterClassForSupplementaryView (typeof(Header), UICollectionElementKindSection.Header, headerId);

saying "kind" is null, which is the middle parameter / UICollectionElementKindSection.Header enum.

To double check that that is null, I added in 
Console.WriteLine ("Header = " + UICollectionElementKindSection.Header);
which prints out "Header = Header"

so something weird is going on here, especially since this then works as expected when adding -f to the additional mtouch arguments.
Comment 16 Zoltan Varga 2013-05-09 16:13:48 UTC
If it works with -f, then it means the AOT cache has a problem somewhere, so the program is basically linked from AOT images which doesn't match the assemblies they are supposed to be compiled from.
Comment 17 Rolf Bjarne Kvinge [MSFT] 2013-05-13 06:35:46 UTC
I'll take this then, since I'm reworking the caching right now anyway.
Comment 18 Zack Gramana 2013-05-14 18:43:52 UTC
I was la able to reproduce this issue in my project. I was building against 3.0.10/6.3.4.36. I was linking an custom built component assembly built against 2.10.12/6.2.4.

-f resolved it.

For me, the offending lines were (either):
- NavigationController.NavigationBar.SetNeedsDisplay()
- NavigationController.NavigationBar.SetBackgroundImage()

Commenting either line out allowed the app to run. Uncommenting either line would re-instate the bug, unless -f was also used.

I had very limited success reduplicating this in a new project, even using the custom build of the component.
Comment 19 branislav 2013-06-17 17:40:54 UTC
I ran into same issue. Here is my case...

1. At the beginning there were few .dat files marked as BundleResource (already deployed to device).
2. Then I change some of .dat files (delete old/insert new/different names)...
3. Rebuild project
4. After that I got malloc error.

It sounds like some kind of bundle signing/checksum problem

(Project > Clean) AND (delete app on device) worked for me..
Comment 20 Rolf Bjarne Kvinge [MSFT] 2013-06-21 09:30:47 UTC
I believe I've fixed this now.

The fix will be included in the next 6.3.* release.

monotouch master-3.0: 55e3c76834f14407882de3156796571887cbec4e