Crash requesting jsondata from NSMutableDictionary created by JSONKit about jsonkit HOT 11 CLOSED

I've tried to recreate this problem, but so far no luck.

It looks like this might be a stack smash from the provided crash dump info.

I did check in 7054853, which includes a number of additional assertions to make sure that the encode cache doesn't copy anything it's not supposed to and accidentally smash the stack in the process.

I can only suggest that you try again with 7054853 and make sure that NS_BLOCK_ASSERTIONS is not enabled, and preferably that the optimizer is turned off. If you continue to have problems, you will probably have to supply the JSON in question so that I can reproduce the problem.

from jsonkit.

I have not been able to reproduce this problem, nor have I heard from anyone else who has encountered this problem. If possible, please provide some example code that reproduces this problem.

from jsonkit.

NSData *data = ...; // Data from an NSURLRequest
JSONDecoder *decoder = [ JSONDecoder decoder];
NSMutableDictionary *jsonData = [ decoder mutableObjectWithData:object.data];
[ jsonData JSONData]; // Crash here

We noticed that this seems to only occur on 64 bit builds and not 32 bit builds.. It also seems to perhaps be specific to a dev seed of a newer OS...

from jsonkit.

Can you provide the JSON?

from jsonkit.

If you need to keep some information about this problem "off the public record", you can email me at john.engelhart AT gmail.com.

Also, I noticed something about the stack trace in the problem description. The problem description states

When requesting jsondata from an NSMutableDictionary created by jsonkit, jsonkit will crash. It works fine for non mutable dictionaries.

However, the stack trace contains:

4   com.myCompany.someApp            0x000000010000ad83 -[NSArray(JSONKit) JSONDataWithOptions:error:] + 67 (JSONKit.m:2891)
5   com.myCompany.someApp            0x000000010000ad38 -[NSArray(JSONKit) JSONData] + 56 (JSONKit.m:2886)
6   com.myCompany.someApp            0x000000010000260d -[someAppAppDelegate someMethod:] + 157 (someAppAppDelegate.m:118)
7   com.apple.CoreFoundation         0x00007fff8ad626ad -[NSObject performSelector:withObject:] + 61

Note that the receiver of the JSONData message has NSArray(JSONKit). This means that the IMP that was selected, based on the class of the receiver, was the NSArray(JSONKit) category version.

It's not possible to tell the class of the receiver from the stack trace. The fact that the stack trace includes the NSArray(JSONKit) JSONData IMP does not necessarily imply the receiver is a JK(Mutable?)Array. Certainly one would never expect the ObjC runtime to dispatch the JKArray(JSONKit) JSONData IMP for a JKDictionary class object.... but if it DID do that, I strongly expect that things would.... not work correctly, and probably crash, as the two object layouts are completely different.

This suggests that adding a quick NSLog("Object class: %@", NSStringFromClass([jsonObject class])); just before the JSONData crashing call would be useful, and report back the result. The expected result would be JKMutableDictionary, and if that is indeed the case AND the stack trace has JKArray(JSONKit), then we've narrowed the problem down a bit..

from jsonkit.

John,

We are working on sanitizing the data and making sure it still occurs
with that version. Once we have that I'll send a sample project over to you.

On Friday, March 25, 2011, johnezang
[email protected]
wrote:

If you need to keep some information about this problem "off the public record", you can email me at john.engelhart AT gmail.com.

Also, I noticed something about the stack trace in the problem description.  The problem description states

When requesting jsondata from an NSMutableDictionary created by jsonkit, jsonkit will crash. It works fine for non mutable dictionaries.

However, the stack trace contains:

4   com.myCompany.someApp            0x000000010000ad83 -[NSArray(JSONKit) JSONDataWithOptions:error:] + 67 (JSONKit.m:2891)
5   com.myCompany.someApp            0x000000010000ad38 -[NSArray(JSONKit) JSONData] + 56 (JSONKit.m:2886)
6   com.myCompany.someApp            0x000000010000260d -[someAppAppDelegate someMethod:] + 157 (someAppAppDelegate.m:118)
7   com.apple.CoreFoundation         0x00007fff8ad626ad -[NSObject performSelector:withObject:] + 61

Note that the receiver of the JSONData message has NSArray(JSONKit).  This means that the IMP that was selected, based on the class of the receiver, was the NSArray(JSONKit) category version.

It's not possible to tell the class of the receiver from the stack trace.  The fact that the stack trace includes the NSArray(JSONKit) JSONData IMP does not necessarily imply the receiver is a JK(Mutable?)Array.  Certainly one would never expect the ObjC runtime to dispatch the JKArray(JSONKit) JSONData IMP for a JKDictionary class object.... but if it DID do that, I strongly expect that things would.... not work correctly, and probably crash, as the two object layouts are completely different.

This suggests that adding a quick NSLog("Object class: %@", NSStringFromClass([jsonObject class])); just before the JSONData crashing call would be useful, and report back the result.  The expected result would be JKMutableDictionary, and if that is indeed the case AND the stack trace has JKArray(JSONKit), then we've narrowed the problem down a bit..

Reply to this email directly or view it on GitHub:
#9 (comment)

from jsonkit.

You might want to try the version of JSONKit.m from commit daf18f3 (and onwards). This commit changes the way in which the immutable / mutable concrete collection classes are done. It also does away with the swizzling hack I had in place which always left me a bit uncomfortable, and I've wondered if that technique didn't play a role in the problem that you're seeing.

from jsonkit.

I will pull an updated version in to our svn Monday and run everything
through our tests again to see if that fixed it!

On Friday, March 25, 2011, johnezang
[email protected]
wrote:

You might want to try the version of JSONKit.m from commit daf18f3 (and onwards).  This commit changes the way in which the immutable / mutable concrete collection classes are done.  It also does away with the swizzling hack I had in place which always left me a bit uncomfortable, and I've wondered if that technique didn't play a role in the problem that you're seeing.

Reply to this email directly or view it on GitHub:
#9 (comment)

from jsonkit.

I've mailed you a sample project that reproduces the crash when compiled + run.

from jsonkit.

This may be a duplicate of issue #15.

from jsonkit.

Fixed in commit c2ef692.

from jsonkit.