Bug 39974 - CMBlockBuffer not getting disposed properly, erroring with "Non-aligned pointer being freed"
Summary: CMBlockBuffer not getting disposed properly, erroring with "Non-aligned point...
Status: VERIFIED FIXED
Alias: None
Product: iOS
Classification: Xamarin
Component: XI runtime ()
Version: XI 9.6 (iOS 9.3)
Hardware: Macintosh Mac OS
: High major
Target Milestone: (C7)
Assignee: Sebastien Pouliot
URL:
Depends on:
Blocks:
 
Reported: 2016-03-29 18:23 UTC by James
Modified: 2016-04-14 17:12 UTC (History)
5 users (show)

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


Attachments
Customer app exhibiting issue (836.44 KB, application/zip)
2016-03-29 18:23 UTC, James
Details
XCode version of app that runs successfully (814.03 KB, application/zip)
2016-03-29 18:24 UTC, James
Details
reduced sample app containing only to the specific code which produces the problem (20.30 KB, application/zip)
2016-03-31 07:30 UTC, g.stechmann
Details
small sample FIXED (20.35 KB, application/zip)
2016-04-06 07:06 UTC, g.stechmann
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:
VERIFIED FIXED

Description James 2016-03-29 18:23:37 UTC
Created attachment 15546 [details]
Customer app exhibiting issue

Customer having issues with video streaming. They are able to do this operation in Objective-C, but when running their Xamarin built version it crashes after a couple frames with the following error:

ElementaryStreamTest2(7265,0xb031b000) malloc: *** error for object 0x16dde260: Non-aligned pointer being freed (2)
*** set a breakpoint in malloc_error_break to debug
2016-03-29 11:09:20.167 ElementaryStreamTest2[7265:548103] critical: Stacktrace:

2016-03-29 11:09:20.167 ElementaryStreamTest2[7265:548103] critical:   at <unknown> <0xffffffff>
2016-03-29 11:09:20.167 ElementaryStreamTest2[7265:548103] critical:   at (wrapper managed-to-native) CoreFoundation.CFObject.CFRelease (intptr) <IL 0x00027, 0xffffffff>
2016-03-29 11:09:20.168 ElementaryStreamTest2[7265:548103] critical:   at CoreMedia.CMBlockBuffer.Dispose (bool) [0x00015] in /Users/builder/data/lanes/2761/d7cac503/source/maccore/src/CoreMedia/CMBlockBuffer.cs:80
2016-03-29 11:09:20.168 ElementaryStreamTest2[7265:548103] critical:   at CoreMedia.CMBlockBuffer.Finalize () [0x00000] in /Users/builder/data/lanes/2761/d7cac503/source/maccore/src/CoreMedia/CMBlockBuffer.cs:64
2016-03-29 11:09:20.168 ElementaryStreamTest2[7265:548103] critical:   at (wrapper runtime-invoke) object.runtime_invoke_virtual_void__this__ (object,intptr,intptr,intptr) <IL 0x00054, 0xffffffff>
2016-03-29 11:09:20.168 ElementaryStreamTest2[7265:548103] critical: 
Native stacktrace:

2016-03-29 11:09:20.173 ElementaryStreamTest2[7265:548103] critical: 	0   ElementaryStreamTest2               0x001fd72d mono_handle_native_sigsegv + 317
2016-03-29 11:09:20.173 ElementaryStreamTest2[7265:548103] critical: 	1   ElementaryStreamTest2               0x002053f1 sigabrt_signal_handler + 145
2016-03-29 11:09:20.173 ElementaryStreamTest2[7265:548103] critical: 	2   libsystem_platform.dylib            0x097e801b _sigtramp + 43
2016-03-29 11:09:20.173 ElementaryStreamTest2[7265:548103] critical: 	3   ???                                 0xffffffff 0x0 + 4294967295
2016-03-29 11:09:20.173 ElementaryStreamTest2[7265:548103] critical: 	4   libsystem_c.dylib                   0x0957565d abort + 156
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	5   libsystem_malloc.dylib              0x0968c585 protect + 0
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	6   libsystem_malloc.dylib              0x09686f40 szone_free + 408
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	7   CoreFoundation                      0x0082b8e8 __CFAllocatorSystemDeallocate + 24
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	8   CoreFoundation                      0x00815f34 CFAllocatorDeallocate + 100
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	9   CoreMedia                           0x04d20d5d BBufFinalize + 188
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	10  CoreFoundation                      0x00828d5c CFRelease + 572
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	11  ???                                 0x19217dbc 0x0 + 421625276
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	12  ???                                 0x1922d614 0x0 + 421713428
2016-03-29 11:09:20.174 ElementaryStreamTest2[7265:548103] critical: 	13  ???                                 0x1922d583 0x0 + 421713283
2016-03-29 11:09:20.175 ElementaryStreamTest2[7265:548103] critical: 	14  ???                                 0x19208d3e 0x0 + 421563710
2016-03-29 11:09:20.175 ElementaryStreamTest2[7265:548103] critical: 	15  ElementaryStreamTest2               0x0026c3c0 mono_gc_run_finalize + 784
2016-03-29 11:09:20.175 ElementaryStreamTest2[7265:548103] critical: 	16  ElementaryStreamTest2               0x002f9fd9 sgen_client_run_finalize + 25
2016-03-29 11:09:20.175 ElementaryStreamTest2[7265:548103] critical: 	17  ElementaryStreamTest2               0x00338fd9 sgen_gc_invoke_finalizers + 89
2016-03-29 11:09:20.175 ElementaryStreamTest2[7265:548103] critical: 	18  ElementaryStreamTest2               0x0026dd5d finalizer_thread + 573
2016-03-29 11:09:20.175 ElementaryStreamTest2[7265:548103] critical: 	19  ElementaryStreamTest2               0x00318564 start_wrapper + 548
2016-03-29 11:09:20.175 ElementaryStreamTest2[7265:548103] critical: 	20  ElementaryStreamTest2               0x00378a50 inner_start_thread + 240
2016-03-29 11:09:20.175 ElementaryStreamTest2[7265:548103] critical: 	21  libsystem_pthread.dylib             0x097d2a26 _pthread_body + 138
2016-03-29 11:09:20.176 ElementaryStreamTest2[7265:548103] critical: 	22  libsystem_pthread.dylib             0x097d299c _pthread_body + 0
2016-03-29 11:09:20.176 ElementaryStreamTest2[7265:548103] critical: 	23  libsystem_pthread.dylib             0x097cff96 thread_start + 34
2016-03-29 11:09:20.176 ElementaryStreamTest2[7265:548103] critical: 
=================================================================
Got a SIGABRT while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries 
used by your application.
=================================================================

The object in question is the following:
GCHandle pinned = GCHandle.Alloc(frame.idr, GCHandleType.Pinned);
IntPtr pointer = pinned.AddrOfPinnedObject();

var buf = CMBlockBuffer.FromMemoryBlock(pointer, (uint)frame.idr.Length, null, 0, (uint)frame.idr.Length, 0, out bberr);

A similar issue also occurs with CMSampleBuffer it appears.

Version Information:
=== Xamarin Studio ===

Version 6.0 (build 4801)
Installation UUID: ab4225ca-dc7f-4d1a-b95e-550f08c30019
Runtime:
	Mono 4.4.0 (mono-4.4.0-branch/f8474c4) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 404000040

=== Xamarin.Profiler ===

Version: 0.22.0.0
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 7.3 (10183.3)
Build 7D175

=== Xamarin.iOS ===

Version: 9.6.0.0 (Business Edition)
Hash: d7cac50
Branch: master
Build date: 2016-03-21 20:13:04-0400

=== Xamarin.Android ===

Version: 6.0.2.1 (Business Edition)
Android SDK: /Users/jamesw/Library/Developer/Xamarin/android-sdk-macosx
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
		5.1    (API level 22)
		6.0    (API level 23)

SDK Tools Version: 25.0.3
SDK Platform Tools Version: 23.1.0
SDK Build Tools Version: 23.0.2

Java SDK: /usr
java version "1.7.0_71"
Java(TM) SE Runtime Environment (build 1.7.0_71-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode)

Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Xamarin Android Player ===

Version: 0.6.5
Location: /Applications/Xamarin Android Player.app

=== Xamarin.Mac ===

Version: 2.4.1.7 (Business Edition)

=== Build Information ===

Release ID: 600004801
Git revision: f73f730c738baf8701a5892b7af64fd468d1dc0c
Build date: 2016-03-14 14:28:06-04
Xamarin addins: 3af7be6c701eb0137645a03e38b82f23b65738c3
Build lane: monodevelop-lion-cycle7

=== Operating System ===

Mac OS X 10.11.3
Darwin jWhite-Mac.local 15.3.0 Darwin Kernel Version 15.3.0
    Thu Dec 10 18:40:58 PST 2015
    root:xnu-3248.30.4~1/RELEASE_X86_64 x86_64
Comment 1 James 2016-03-29 18:24:13 UTC
Created attachment 15547 [details]
XCode version of app that runs successfully
Comment 2 Sebastien Pouliot 2016-03-29 18:36:11 UTC
@Alex can you have a look at the sample and ensure memory is handled correctly? Thanks.
Comment 3 g.stechmann 2016-03-31 07:30:39 UTC
Created attachment 15566 [details]
reduced sample app containing only to the specific code which produces the problem

this app demonstrates the issue
Comment 4 g.stechmann 2016-03-31 12:02:07 UTC
short explanation of the example code uploaded on 31st of march:

please look inside ViewController class.

the error appears whenever
CMBlockBuffer.Dispose() is called explicity,
or the Garbagecollector tries to clean up CMBlockBuffer objects.
Comment 5 Sebastien Pouliot 2016-04-06 00:09:33 UTC
I only looked to the last, smaller, sample tonight but here's a short answer:

* The code is simpler if you let iOS allocates the memory (i.e. use IntPtr.Zero as the first parameter) and it's possible to access the unmanaged memory form managed code. I tend to favour that but I understand there can be reasons to want the memory managed.

* The (last) sample is incorrect, you're pinning the managed memory (fine) before the call to `FromMemoryBlock`.

However you're freeing the GCHandle _before_ disposing of the `CMBlockBuffer`, which makes it possible for the GC to move the memory - and that is still referenced by the `buf` instance.

Changing the order of the calls to

> buf.Dispose ();
> pinned.Free();

fix the crash for me. I'll double check my results tomorrow with your original sample.
Comment 6 Sebastien Pouliot 2016-04-06 01:01:42 UTC
For the 2nd part to work you need another fix, that I had locally, based on earlier Alex's comments about `kCFAllocatorNull != null` (i.e. a `null` allocator is `kCFAllocatorDefault` which is easy to miss/forget while reading code).

> var buf = CMBlockBuffer.FromMemoryBlock (...);

with

> var buf = FromMemoryBlock (...);

where the later is the code from

https://gist.github.com/spouliot/a1e7d90015c22445afb205c74ceb5b0b
Comment 7 g.stechmann 2016-04-06 07:06:27 UTC
Created attachment 15622 [details]
small sample FIXED

this is the fixed version that runs properly. just in case someone finds it usefull
Comment 8 g.stechmann 2016-04-06 07:07:16 UTC
i was able to fix the sample based on the information provided. thank you very much!
Comment 9 Sebastien Pouliot 2016-04-06 14:08:18 UTC
Thanks for confirming!

The fix has been backported to C7 (so newer XI 9.8 builds will include it) and we're looking into providing easier API (e.g. directly accepting a `byte[]`) for the next cycle.

Fixed in
maccore/master ef83408f50090116c012e5fb6b88ce45f6c9838c
maccore/cycle7 90aa41816f9b2e9a8d323b579bf54fecece0a5d7


QA: unit test was added in 
maccore/master fd45d97f0c31fbe1dac265c3dbf576889aabe99a
maccore/cycle7 291a400c329c48bfc1b301857816579755b3374a

but the latest sample (https://bugzilla.xamarin.com/attachment.cgi?id=15622) can be used to double-check (it should not crash).

C8 task: https://trello.com/c/RX7BMktQ
Comment 10 GouriKumari 2016-04-14 17:12:20 UTC
Verified with ElementaryStreamTest sample and it didn't crash on device. 


## Logs:
https://gist.github.com/GouriKumari/26cf1d520cd466b5c471073c2b0ada45

## Test Env:=== Xamarin Studio Business ===

Version 6.0 (build 4968)
Installation UUID: fafd3486-1aec-4f9c-ab77-08bf4a000708
Runtime:
	Mono 4.4.0 (mono-4.4.0-branch/a3fabf1) (64-bit)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 404000122

=== Xamarin.Profiler ===

Version: 0.29.99
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Apple Developer Tools ===

Xcode 7.3 (10183.3)
Build 7D175

=== Xamarin.iOS ===

Version: 9.8.0.252 
Hash: 3daf751

=== Build Information ===

Release ID: 600004968
Git revision: ab7092ce63351276394f283e4f9c8646baf51fce
Build date: 2016-04-08 09:30:34-04
Xamarin addins: be0a0aef6ec8b075b4ba4690bd147d1e33c2abd7
Build lane: monodevelop-lion-cycle7

=== Operating System ===

Mac OS X 10.11.3