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)

See Also:
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

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

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