my advice is to measure How can I measure? Does VMTracker do the job? I'd like to add that our crash reports have VM Region Summary. In all of the reports I've looked through there is the same total Virtual Size at around 5.2-5.3 GB. Is it too small or too large? I'm not familiar with the VM size limits, but these sizes are surprisingly constant throughout the reports. Part of the issue is that JavaScriptCore is reserving more address space than it should on lower memory devices As for JS, in the same reports it is being said that JS VM Gigacage takes 1GB. On the other hand we have 2GB in the _TEXT section - that is unexpectedly large value. For example: VIRTUAL REGION REGION TYPE SIZE COUNT (non-coalesced) =========== ======= ======= Activity Tracing 256K 1 AttributeGraph Data 1024K 1 Audio 64K 1 CG raster data 112K 2 CoreAnimation 48K 3 Foundation 400K 3 JS VM Gigacage (reserved) 1.0G 1 reserved VM address space (unallocated) Kernel Alloc Once 32K 1 MALLOC 805.0M 200 MALLOC guard page 4016K 4 Mach message 16K 1 SQLite page cache 2688K 21 STACK GUARD 1152K 72 Stack 47.7M 74 Stack Guard 16K 1 VM_ALLOCATE 516.8M 4042 VM_ALLOCATE (reserved) 512K 8 reserved VM address space (unallocated) WebKit Malloc 256.1M 8 __AUTH 12.0M 968 __AUTH_CONST 126.2M 1418 __CTF 824 1 __DATA 75.6M 1374 __DATA_CONST 46.9M 1430 __DATA_DIRTY 12.3M 1237 __FONT_DATA 2352 1 __LINKEDIT 191.1M 10 __OBJC_RO 84.6M 1 __OBJC_RW 3180K 1 __TEXT 2.0G 1452 __TPRO_CONST 128K 2 mapped file 135.2M 1841 page table in kernel 1476K 1 shared memory 80K 4 =========== ======= ======= TOTAL 5.3G 14185 TOTAL, minus reserved VM space 4.3G 14185

Thank you for this thorough analysis. My bad providing you with the TOP crash without the crashing thread' stack. The top frames in the neighbouring crash reports are the same as in FMOD crash. The MemoryAllocator thing there is Unity's entry point for Native allocators. Not sure if that would shed some light on the internals though. So, you need to start investigating your virtual address space, that is: Whether your app is using more virtual address space for some reason. Or whether iPadOS is giving your less virtual address space to play with. Doesn't the fact that it happens only on certain latest iPadOS versions prove than iPadOS is giving us less? If you don't think so, then could you please describe any method of diagnosing virtual address space? The only thing I can think of is using VM Tracker instrument. But as we are not the Unity engine developers, we'll definitely fail in attributing VM regions. The other option for us is using Extended Virtual Addressing Entitlement. I believe enabling it has some drawbacks, but don't know which ones.

We have lots of different crashes that have callstacks of the crashing thread ending with memory allocation routines. They may be or may be not Unity-specific. We even do have JSC-related crashlog as I see it now (I believe it is Ads-related WebView content). In Organizer there is a pie-chart showing the OS version the crashes happen on. Some crashes have only 26.4 and 26.5 mentioned. The others may have earlier OS versions, while the percentage is still mostly in the freshest 26.4+26.5). Here are some examples from live users and screenshots with pie-charts: FMOD.crash JSC.crash Network.crash SceneLoading_TOP.crash WebView.crash

I'm not sure if I can really distinct the event types by the log report (.ips) now due to regular log format changes... From my POV, it doesn't look like a jetsam event. It does not have anything from the documentation page you've mentioned. On the other hand the log we have doesn't look like a regular crash report either. It does contain the following though: "exception" : {"codes":"0x0000000000000001, 0x00000000000000c0","rawCodes":[1,192],"type":"EXC_BAD_ACCESS","signal":"SIGSEGV","subtype":"KERN_INVALID_ADDRESS at 0x00000000000000c0"}, "termination" : {"flags":0,"code":11,"namespace":"SIGNAL","indicator":"Segmentation fault: 11","byProc":"exc handler","byPid":599}, "ktriageinfo" : "VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\nVM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\nVM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\nVM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\nVM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter\n", "vmregioninfo" : "0xc0 is not in any region.... Also, I've attached a pair of such logs to my FB mentioned earlier.

We track consumed memory level got from TASK_VM_INFO.phys_footprint. The app crashes at ~1.26GB on iPads with 3GB of RAM. At the same time os_proc_available_memory() shows there's still about 580MB available memory. Our apps are Unity-based games, so JavaScriptCore is definitely not involved. Moreover, we see crashes only on iPadOS versions 26.4+. On earlier versions (e.g. iPadOS 18.7) our games don't crash or crash much less frequently at around 1.8GB consumed memory.

We're seeing the same thing, but with additional nuances. I've filed a bug report FB22883960. The strange thing here is that os_proc_available_memory() shows there's plenty to take, but the app still crashes upon reaching a reduced limit. Moreover, I think, the system is not fully aware of the lowered limit, or there is sort of a bug with the limit itself, as if it had been lowered unintentionally.