Posts

Post not yet marked as solved
2 Replies
391 Views
Considering this code: var taskInfoData = task_vm_info_data_t() var count = mach_msg_type_number_t(MemoryLayout<task_vm_info>.size) / 4 // sizeof(natural_t) let result: kern_return_t = withUnsafeMutablePointer(to: &taskInfoData) { $0.withMemoryRebound(to: integer_t.self, capacity: 1) { task_info(mach_task_self_, task_flavor_t(TASK_VM_INFO), $0, &count) } } var physicalFootprintBytes: Int64? = nil var availableMemoryBytes: Int64? = nil if result == KERN_SUCCESS { // https://github.com/apple/darwin-xnu/blob/2ff845c2e033bd0ff64b5b6aa6063a1f8f65aa32/osfmk/kern/task.c#L5396 // kTaskVMInfoRev1Count is defined in the bridging header if count >= kTaskVMInfoRev1Count { physicalFootprintBytes = Int64(taskInfoData.phys_footprint) } // Does not work if count >= kTaskVMInfoRev4Count { availableMemoryBytes = Int64(taskInfoData.limit_bytes_remaining) } } I built this code in Xcode 12.5 using the iPhoneOS 14.5 SDK targeting iOS 12.0. I ran this code on an iPhone 11 with iOS 14.8. I expected both the phys_footprint and limit_bytes_remaining fields to have sane values, but limit_bytes_remaining was zero. TASK_VM_INFO_COUNT in <mach/task.info> is 87 and my code (mach_msg_type_number_t(MemoryLayout<task_vm_info>.size) / 4) is also 87. However, the return value of the count variable is 42. This is equivalent to TASK_VM_INFO_REV2_COUNT in <mach/task.info>. After reading the XNU code, I found that there is a workaround to handle the wrong length [1]. I think this logic affects this code, but I don't know why. Is it considered a bug? Or are there any problems with my code? Does the deployment target of the app (currently iOS 12.0) affect this? [1] https://github.com/apple/darwin-xnu/blob/2ff845c2e033bd0ff64b5b6aa6063a1f8f65aa32/osfmk/kern/task.c#L5244
Posted
by bc_lee.
Last updated
.