On 29 Mar 2011, at 01:01, David Chisnall wrote: > Hello the list, > > I spent some time with valgrind and found out why NSConnection is so flakey > on 64-bit platforms. It seems that we use the same incorrect pattern in a > lot of places throughout the class. We probably use it in other places, so > it would be worth doing a brief audit for this bug before the next release. > I had a quick look, and I think that NSConnection is the only place where we > use GSIMap with something other than pointers. > > The problem is in statements like this: > > node = GSIMapNodeForKey(IreplyMap, (GSIMapKey)seq); > > Looks fine? The problem is that (GSIMapKey) is a union (something concealed > by the fact that it is a macro - unions are difficult to use safely, and > anything that hides the fact that you are using a union is generally a bad > thing). Specifically, it's a problem that GSIMapKey is a union of void*, id, > unsigned, and int. On most current 64-bit platforms, unsigned and int are > 32-bit quantities, while void* and id are 64-bit quantities. > > The problem, therefore, is that the we are defining 4 bytes of an 8-byte > quantity and then (in the callee) accessing all 8 bytes. This results in > some random behaviour. The connection.m test was failing because sometimes > the uninitialised bytes were 0 (so the map was finding the value it was > looking for) and sometimes they were some other value from the stack.
Well spotted. I've implemented a fix for that throughout base. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
