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.
Running the latest alpha (Version: 184.108.40.206 (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
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
even though the value "Kind" is not null.
Redth, can you attach a crash report?
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.
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 ?
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 :/
I cannot reproduce it with the binaries for that sample.
Created attachment 3935 [details]
Here's the actual .app that just caused this for me right now:
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 ?
This could be caused by the AOT image caching stuff. Is there a way to turn that off ?
Add -f to the additional mtouch arguments to always force a recompile.
Adding in -f seems to fix the problem, let me try and get you that info Zoltan for Release mode.
Here's the release crash - not sure if you need anything else: https://gist.github.com/chrisntr/f107e5f0ce9cef56d673
That seems to be a completely unrelated problem, its not a crash, but an unhandled exception.
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.
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.
I'll take this then, since I'm reworking the caching right now anyway.
I was la able to reproduce this issue in my project. I was building against 3.0.10/220.127.116.11. 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):
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.
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..
I believe I've fixed this now.
The fix will be included in the next 6.3.* release.
monotouch master-3.0: 55e3c76834f14407882de3156796571887cbec4e