Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

removeObjectsForKeys doesn't properly remove objects #17

Closed
jfmorin opened this issue Apr 19, 2011 · 8 comments
Closed

removeObjectsForKeys doesn't properly remove objects #17

jfmorin opened this issue Apr 19, 2011 · 8 comments
Assignees

Comments

@jfmorin
Copy link

jfmorin commented Apr 19, 2011

Hi,

There is a problem with the NSMutableDictionary returned by mutableObjectFromJSONString. A call to removeObjectsForKeys will remove the objects but not the keys. So we end up with nil objects. I also noticed side effects on other dictionary values that should not be affected.

Should it be overridden in the JKDictionary class like removeObjectForKey is?

Thanks,
JF

@johnezang
Copy link
Owner

Can you provide the JSON and some example code the demonstrates the problem?

From your description, it's not clear what the problem is. When you say "A call to removeObjectsForKeys will remove the objects but not the keys. So we end up with nil objects.", this is the expected behavior- when a NSDictionary does not contain a key, -objectForKey: will return nil (aka NULL).

@jfmorin
Copy link
Author

jfmorin commented Apr 21, 2011

Instead of removing the key/value pair as expected, the key remains in the mutable dictionary but the value is replaced by a null value. If I print the resulting object I can see: "myKey"=(null).

@johnezang
Copy link
Owner

The behavior you describe is the expected behavior. The key does not "remain" in the dictionary, any key that does not exist in the dictionary returns NULL (aka nil). There are a number of internal checks in the form of NSCParameterAssert that ensure that every key in the dictionary contains a non-NULL object associated with it. If you did not compile JSONKit with NS_BLOCK_ASSERTIONS, these checks are enabled, and would have caused an exception, which would have been logged to the console.

I suggest you try creating a NSMutableDictionary with a number of keys/objects. Remove one of the keys, and see if the NSMutableDictionary has the same behavior for the removed key.

@omarkilani
Copy link

Hey John,

I think what the OP is seeing is this (with JSONKit 2e6ccf4):

Code:

  NSMutableDictionary *jkDict = [@"{\"a\":\"1\",\"b\":\"2\",\"c\":\"3\"}" mutableObjectFromJSONString];
  NSLog(@"jkDict = %@", jkDict);

  NSMutableDictionary *objcDict = [NSMutableDictionary dictionaryWithObjectsAndKeys:@"1", @"a", @"2", @"b", @"3", @"c", nil];
  NSLog(@"objcDict = %@", objcDict);

  [jkDict removeObjectForKey:@"b"];
  [objcDict removeObjectForKey:@"b"];

  NSLog(@"jkDict = %@", jkDict);
  NSLog(@"objcDict = %@", objcDict);

Output:

2011-04-22 14:46:05.354 main[90231:903] jkDict = {
    a = 1;
    b = 2;
    c = 3;
}
2011-04-22 14:46:05.357 main[90231:903] objcDict = {
    a = 1;
    b = 2;
    c = 3;
}
2011-04-22 14:46:05.358 main[90231:903] jkDict = {
    a = 1;
    c = (null);
}
2011-04-22 14:46:05.358 main[90231:903] objcDict = {
    a = 1;
    c = 3;
}

@omarkilani
Copy link

Hey John,

I've tracked this down to the fix which fixed issue #8 :)

524b9d7

Specifically this line:

524b9d7#L0R1014

This comment:

// If the key was in the table, we would have found it by now.

Is incorrect if removeObjectForKey was used (like my example above).

dictionary->entry looks like this with the example:

[0] = {keyHash = 1062, key = @"a", object = "1"}
[1] = {keyHash = 0, key = NULL, object = NULL}
[2] = {keyHash = 1068, key = @"c", object = "3"}

So the loop terminates with NULL due to [1], but we need to keep going to find [2].

@johnezang
Copy link
Owner

@omarkilani, the line you mentioned in your comment is one half of the problem. The real problem is in the removal logic- it (should have) "re-added" the items following the removed entry so that linear probe hash collisions didn't result in a NULL gap in the middle of the linear probe hash collision.

Your example code was very useful- it happened to create a dictionary with 3 items with a capacity of 3 items, and a, b, and c all just happened to be ≡ 0 mod 3. Sort of a "perfect storm" to exercise this bug.

I checked in a bug fix for this issue (used the new github issues feature to close this issue automagically with "Closes #17").

@jfmorin
Copy link
Author

jfmorin commented Apr 22, 2011

Thanks for the help reproducing the problem and fixing it.
Good job!

@omarkilani
Copy link

@johnezang, Thanks for the fix. Yeah, the real problem became obvious once I started delving in a bit more. I seem to get pretty lucky with just the right dictionaries to trigger things. :)

Thanks again.

aussiegeek added a commit to playup/JSONKit that referenced this issue May 4, 2011
* 'master' of github.com:playup/JSONKit:
  Adds a serializing option to backslash escape forward slashes.  This is for issue johnezang#21.
  Change a NSException from exceptionWithName: to raise:.  Closes johnezang#20.
  Fixes a bug when removing items from a JKDictionary.  Since JKDictionary is implemented using a hash table that uses linear probing, the removal function needs to "re-add" items that follow the removed item so that linear probe hash collisions are not "lost".  Closes johnezang#17
@ghost ghost assigned johnezang May 21, 2011
jasongregori pushed a commit to jasongregori/JSONKit that referenced this issue Sep 23, 2011
…ry is implemented using a hash table that uses linear probing, the removal function needs to "re-add" items that follow the removed item so that linear probe hash collisions are not "lost". Closes johnezang#17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants