NSConcretePointerFunctions implementation is incorrect for non-default options #311
Labels
bug
Use this tag for reporting bugs or issues that impede the software's normal functionality.
help wanted
Mark issues that are open for contributions with this tag.
There are some serious issues with the implementation of
NSConcretePointerFunctions
, especially w.r.t. theNSPointerFunctionsOptions
enum and the initialization ofPFInfo
. I briefly tried to fix these problems locally, but the fixes soon spiraled into fixes toNSConcreteMapTable
,NSPropertyList
, and so on; so I'm just going to leave an issue here.A couple concrete issues that I can be 100% certain about:
NSPointerFunctionsOptions
are not bitfields. In other words, most of the options don't have a mutually-exclusive bitwise representation (they are just sequential integers). However in the vast majority of places that interacts with these options, they are treated as bitfields and bitwise-AND'ed against in an attempt to determine if they are "set". This produces completely unexpected behaviour.initWithOptions
function in NSConcretePointerFunctions.m (apart from its issues with said enum values) also does not correctly set the fields of itsPFInfo _x
instance variable. An example of this is theacquireFunction
function pointer, which doesn't get set based on the Memory flags, but instead gets set based on the Personality flags, which should only affect thehashFunction
,isEqualFunction
, anddescribeFunction
fields. So in many cases, theacquireFunction
will be mis-set, which can cause all sorts of memory issues (for example, a non-objc pointer could be casted toid
and then sent aretain
message).In addition to those concrete issues, I'm fairly certain that there are some issues with the way that weak pointers are handled, especially in
NSConcreteMapTable
which "overrides" parts of theNSPointerFunctions
functionality, presumably because it wasn't working. There is a comment about this from 2013. When I locally tried to patch theNSConcretePointerFunctions
implementation, it cascaded into spooky memory issues inNSConcreteMapTable
,NSPropertyList
, and so on. I assume this is because those implementations have unknowingly been relying on unexpected behaviour fromNSConcretePointerFunctions
.As mentioned, I am not going to fix these problems myself as the attempted fix grew well outside of my scope, but I'm leaving this issue here because it is a rather large potential source of memory corruption issues, memory leaks, and so on.
The text was updated successfully, but these errors were encountered: