Memory leak in si_user_byuid/getpwuid originating from CPSharedResourcesDirectory in iOS

253 Views Asked by At

I am at the optimizing/analysing phase of a product that will go live in a couple of weeks, and I am astonished to find some leaks that do not (I believe) originate from my code. One of them is the strdup/malloc leak present in iOS 5.1.1, for which I can do nothing other than wait for an update. However today I have discovered a new one, and I'm currently trying to pinpoint where and how its leaking. Instruments reports:

     Bytes Used         # Leaks Symbol Name
     16 Bytes  100.0%   1       start
     16 Bytes  100.0%   1        main
     16 Bytes  100.0%   1         UIApplicationMain
     16 Bytes  100.0%   1          -[UIApplication _run]
     16 Bytes  100.0%   1           _UIAccessibilityInitialize
     16 Bytes  100.0%   1            -[UIApplication(UIKitApplicationAccessibility) _accessibilityInit]
     16 Bytes  100.0%   1             -[UIApplication(UIKitApplicationAccessibility) _updateAccessibilitySettingsLoader]
     16 Bytes  100.0%   1              _AXSAccessibilityEnabled
     16 Bytes  100.0%   1               _getBooleanPreference
     16 Bytes  100.0%   1                CPCopySharedResourcesPreferencesDomainForDomain
     16 Bytes  100.0%   1                 CPSharedResourcesDirectory
     16 Bytes  100.0%   1                  getpwuid
     16 Bytes  100.0%   1                   si_user_byuid
     16 Bytes  100.0%   1                    search_item_bynumber
     16 Bytes  100.0%   1                     si_user_byuid
     16 Bytes  100.0%   1                      _fsi_get_user
     16 Bytes  100.0%   1                       0x119048
     16 Bytes  100.0%   1                        0x1180e4
     16 Bytes  100.0%   1                         malloc

From a little digging I did, I found out that getpwuid is a unix/linux function imported by <pwd.h>. Double-clicking on si_user_byuid in Instruments comes up with a "No Source" sign, and double-clicking on getpwuid comes up with arm7 assembly (which I am sorry to inform you Im not familiar with):

+0x0    push                           {r4, r5, r7, lr}
+0x2    add                            r7, sp, #8
+0x4    movw.w                         r5, #18506  ; 0x484a
+0x8    movt.w                         r5, #3265  ; 0xcc1
+0xc    mov                            r4, r0
+0xe    add                            r5, r15
+0x10   ldr                            r0, [r5]
+0x12   cbnz                           getpwuid
+0x14   movw.w                         r0, #47748  ; 0xba84
+0x18   movt.w                         r0, #1  ; 0x1
+0x1c   add                            r0, r15
+0x1e   bl.w                           getpwuid
+0x22   str                            r0, [r5]
+0x24   mov                            r1, r4
+0x26   bl.w                           getpwuid
+0x2a   mov                            r4, r0
+0x2c   movs                           r0, #201  ; 0xc9
+0x2e   mov                            r1, r4
+0x30   bl.w                           getpwuid
+0x34   movs                           r0, #0  ; 0x0
+0x36   cmp                            r4, #0  ; 0x0
+0x38   it                             ne
+0x3a   addne.w                        r0, r4, #28  ; 0x1c
+0x3e   pop                            {r4, r5, r7, pc}

So:

  • Has anyone seen this before ?
  • Could it be a false-positive ?
  • Could it be limited to iOS 5.1.1 ?
1

There are 1 best solutions below

1
On

Here's the source of the whole thing starting from getpwuid. From a quick look, it seems there's some caching going on, so I wouldn't worry too much unless the leak is big.