Action Extension Memory Limit Crashes

Especially on iOS you can find yourself in this position if your application uses too much memory. Applications and especially demons are often sandboxed for memory usage. Using too much memory will yield the exception of this kind. You can read more about it here:

https://developer.apple.com/documentation/metrickit/improving_your_app_s_performance/reducing_your_app_s_memory_use

If you simply crash in this vImage function with EXC_BAD_ACCESS or similar then that is a strong indication that the buffer passed to vImage was too small, non existent or not writeable. The vImage routine simply writes a byte to the last valid byte in the vImage_Buffer to see what will happen. If all is well, it goes through and nobody notices. If the buffer is too small (depressingly common) then the write may run off the end of the buffer and cause a crash. This is a signal that the bug is in the callers code and not a problem in vImage. (As the framework ultimately responsible for touching potentially improperly configured pixel buckets, vImage would otherwise find itself having to diagnose a lot of other people's bugs, so it is there as a means of self defense.) You can use vImageBuffer_Init to allocate buffers for you to help reduce this sort of error. Otherwise, you can use vmmap <pid> to dump a list of the application's allocations to go look at whether the crash data address is in the buffer that it is supposed to be in or somewhere off the end. Vmmap will also tell you whether the allocation is readonly or readwrite. If you aren't the one calling vImage directly, then the error might lie in the callers code, or potentially could be in an incorrectly allocated CFData, CGImageDestination, or similar. Where are those pixels supposed to end up? Look there.

Note that vmmap shows the view of memory from the perspective of virtual memory -- the set of large page aligned allocations that underlie what is going on in the system. It is also the granularity along which memory protection functions. For smaller allocations, malloc() allocates a biggish chunk of page aligned memory and then sub allocates from there as needed. So, while you will see the large page aligned buffer that contains your 16-byte allocation, it won't be stored individually as such, unless MallocGuardEdges, GuardMalloc or similar is on.

Also actual for me. I am trying to apply exposure filter on local video with usage of ffmpeg-kit library and got: Thread 358: EXC_RESOURCE (RESOURCE_TYPE_MEMORY: high watermark memory limit exceeded) (limit=2098 MB)