Post not yet marked as solved
Post marked as unsolved with 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