SIGSEGV when creating invalid AVAssetWriterInput

[tipa]

Apple platform

iOS

Framework version

net9.0-*

Affected platform version

.NET 9.0.8, iOS workload 18.5.9215

Description

I've come across a situation where I created an invalid AVAssetWriterInput, which - as expected - throws an ObjCException. However, my app crashes even when I catch this exception.
Using GC.Collect(); can make the crash occur more reliably in a test project. It probably is related to garbage collection.

I have experienced the same crash on macOS, however I cannot reproduce it with the minimal example below, which only crashes the app on iOS. If needed, I can try to prepare a more complete example that also reproduces the crash on macOS.
Based on the stack trace that I've seen in the macOS crash dialog (see below), it might to be related to those crash reports:
#10562
#19493

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000020
Exception Codes:       0x0000000000000001, 0x0000000000000020

Termination Reason:    Namespace SIGNAL, Code 11 Segmentation fault: 11
Terminating Process:   exc handler [10598]

VM Region Info: 0x20 is not in any region.  Bytes before following region: 4329455584
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                      1020e4000-102238000    [ 1360K] r-x/r-x SM=COW  /Users/USER/*/MyApp1/Contents/MacOS/MyApp1

Application Specific Backtrace 0:



Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libobjc.A.dylib               	       0x18ba60028 objc_release + 16
1   Diarium                       	       0x102106278 xamarin_release_managed_ref + 100 (runtime.m:1842)
2   ???                           	       0x10db0e8cc ???
3   ???                           	       0x10db0e0ec ???
4   ???                           	       0x10dd4fe0c ???
5   ???                           	       0x1086b74c8 ???
6   ???                           	       0x107302a2c ???
7   ???                           	       0x10731d2cc ???
8   ???                           	       0x1080ec828 ???
9   ???                           	       0x1080ebe04 ???
10  ???                           	       0x1080ebc7c ???
11  MyApp1                       	       0x10210199c xamarin_bridge_runtime_invoke_method + 124 (delegates.inc:1683)
12  MyApp1                       	       0x102112b18 mono_runtime_invoke + 72 (coreclr-bridge.m:861)
13  MyApp1                       	       0x102181120 native_to_managed_trampoline_96(objc_object*, objc_selector*, _MonoObject**, objc_object*, unsigned int) + 348 (Microsoft.macOS.registrar.coreclr.arm64.m:6519)
14  MyApp1                       	       0x102180fb8 +[__NSObject_Disposer drain:] + 52 (Microsoft.macOS.registrar.coreclr.arm64.m:48679)
15  Foundation                    	       0x18d52af74 __NSThreadPerformPerform + 264
16  CoreFoundation                	       0x18bf3eb14 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
17  CoreFoundation                	       0x18bf3eaa8 __CFRunLoopDoSource0 + 172
18  CoreFoundation                	       0x18bf3e814 __CFRunLoopDoSources0 + 232
19  CoreFoundation                	       0x18bf3d468 __CFRunLoopRun + 840
20  CoreFoundation                	       0x18bf3ca98 CFRunLoopRunSpecific + 572
21  HIToolbox                     	       0x1979df27c RunCurrentEventLoopInMode + 324
22  HIToolbox                     	       0x1979e24e8 ReceiveNextEventCommon + 676
23  HIToolbox                     	       0x197b6d484 _BlockUntilNextEventMatchingListInModeWithFilter + 76
24  AppKit                        	       0x18fe61a34 _DPSNextEvent + 684
25  AppKit                        	       0x190800940 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
26  AppKit                        	       0x18fe54be4 -[NSApplication run] + 480
27  AppKit                        	       0x18fe2b2dc NSApplicationMain + 880
28  ???                           	       0x1080e7ba4 ???
29  ???                           	       0x1080e7898 ???
30  ???                           	       0x1080d405c ???
31  libcoreclr.dylib              	       0x1039e3a9c CallDescrWorkerInternal + 132
32  libcoreclr.dylib              	       0x1038676f4 MethodDescCallSite::CallTargetWorker(unsigned long long const*, unsigned long long*, int) + 832
33  libcoreclr.dylib              	       0x10376b9dc RunMain(MethodDesc*, short, int*, PtrArray**) + 624
34  libcoreclr.dylib              	       0x10376bd38 Assembly::ExecuteMainMethod(PtrArray**, int) + 268
35  libcoreclr.dylib              	       0x10379037c CorHost2::ExecuteAssembly(unsigned int, char16_t const*, int, char16_t const**, unsigned int*) + 640
36  libcoreclr.dylib              	       0x10375b3f4 coreclr_execute_assembly + 232
37  MyApp1                       	       0x10211285c mono_jit_exec + 196 (coreclr-bridge.m:767)
38  MyApp1                       	       0x1021166ec xamarin_main + 836 (monotouch-main.m:460)
39  MyApp1                       	       0x1021b4f64 main + 64 (main.arm64.mm:67)
40  dyld                          	       0x18bab2b98 start + 6076

Steps to Reproduce

try
{
    _ = new AVAssetWriterInput(AVMediaTypes.Audio.GetConstant(), new AudioSettings
    {
          Format = AudioFormatType.MPEG4AAC,
          EncoderBitRate = 32000,
          NumberChannels = 2,
        // SampleRate = 16000,
    });
}
// NSInvalidArgumentException Reason: *** -[AVAssetWriterInput initWithMediaType:outputSettings:sourceFormatHint:] Missing required key AVSampleRateKey
catch (Exception e) { Console.WriteLine(e); }
GC.Collect();

Example project: test_ios.zip

Did you find any workaround?

No response

Relevant logs

No response

[rolfbjarne]

I can reproduce the problem with the test project, thanks.

I think this is because our handling of alloc+init is slightly incorrect: calling init will invalidate the handle returned by alloc, but we happily try to free it if init throws an exception (because we never get to overwrite the now invalid handle from alloc with the valid handle from init).

This seems related to #9478, where there's a related problem: if init is frees the handle from alloc (with the intention of returning a new handle), confusion arises on our side if another thread re-uses the freed memory/handle for a different object.