Swift 4.1: _CFDeinit function in CFRuntime.c -> cfinfoa

Development Core Libraries
1

I am debugging testcase failures on s390x architecture and noticed that NSDate.swift:43 calls _CFDeinit function to run some finalizers. Part of _CFDeinit function calculates the __CFInfoType from which it derives typeID of the object.

On x86, value and memory contents of cf is as follows:
(lldb) fr v info
(__CFInfoType) info = 8832
(lldb)

(lldb) fr v cf
(CFTypeRef) cf = 0x00005555562dfd40
(lldb) me read --count 64 0x00005555562dfd40
0x5555562dfd40: 68 60 7d f7 ff 7f 00 00 02 00 00 00 03 00 00 00 h`}.............
0x5555562dfd50: 80 22 00 00 00 00 00 00 11 e5 31 9d b5 49 c0 41 ."........1..I.A
0x5555562dfd60: 30 00 00 00 00 00 00 00 61 00 00 00 00 00 00 00 0.......a.......
0x5555562dfd70: 02 00 00 00 00 00 00 00 80 9c f4 f5 ff 7f 00 00 ................

on s390x arch, value and memory contents are as follows:
(lldb) fr v info
(__CFInfoType) info = 37933151158272

(lldb) me read --count 64 0x000002aa00e671b0
0x2aa00e671b0: 00 00 03 ff fd 82 f9 c8 00 00 00 03 00 00 00 02 ................
0x2aa00e671c0: 00 00 22 80 00 00 00 00 41 c0 49 e5 3d 83 31 db ..".....A.I.=.1.
0x2aa00e671d0: 00 11 00 00 00 00 fe 12 00 00 00 00 00 00 00 21 ...............!
0x2aa00e671e0: 00 00 02 aa 00 d9 2f 30 00 00 02 aa 00 d9 2e 60 ....../0.......`

On s390x, value of info causes a __HALT() routine to be invoked thus failing the testcase.

It is obvious from the memory layout and the contents that on s390x 8 byte value of 00 00 22 80 00 00 00 00 translates to this humongous number. This appears to me as cfinfoa structure being set incorrectly somewhere or not getting aligned properly. Only places I see this happen is in CFRuntime.c and CFString.h but looking at the code I did not find any obvious place this could happen.

I can make it work by changing info to "info = info >> 32;"

However, I would like to fix it correctly but am unable to figure out where does this get set in the context of NSDate.swift for example.

Thanks for any pointers.

2

Hi @rishi,

Another thought: is this an endianness issue? We may have a few places left where we assume little endian.

cfinfoa is there to store some metadata bits for each instance of a CFTypeRef.

3

Hi @Tony_Parker - yes, this is running on Big Endian and this is more than likely an endian issue as you point out. We are already addressing the endiness gaps and having some success with moving forward but lot remains to be solved.

This structure (cfinfoa) was changed in 4.1 to make it a unint64_t. CFRuntime.h is one possible place where this structure is written into. I notice that it always retains x80 value in most of the cases. Would you know how CFTypeRef gets instantiated in the context of NSDate.swift?

Thanks