Can't decode an SFSObject. Byte data is insufficient

[janheuninck]

Hi guys,

Lately we are experiencing a lot of crashes on our client (ios devices, all using the latest SFS API [1.1.1]). When we run the application without attaching it to Xcode, these exceptions seems to be ignored. If we debug in Xcode however, the entire application crashes when the exception occurs. The annoying thing is that this happens very often! Is there a way to put this SFS function between inside a try-catch block to prevent the application from crashing and show a error message instead?

Do you guys also have any idea why this exception occurs?


Thanks!

Code: Select all

2012-10-25 11:13:41.939 ProjectX[34804:707] Uncaught EXCEPTION: Can't decode an SFSObject. Byte data is insufficient. Size: 0 byte(s)
2012-10-25 11:13:41.985 ProjectX[34804:707] Stack Trace: (
    0   CoreFoundation                      0x35d9e8a7 __exceptionPreprocess + 186
    1   libobjc.A.dylib                     0x31717259 objc_exception_throw + 32
    2   ProjectX                            0x00112ef3 -[DefaultSFSDataSerializer binary2object:] + 162
    3   ProjectX                            0x00127c15 +[SFSObject newFromBinaryData:] + 80
    4   ProjectX                            0x0012a135 -[SFSProtocolCodec onPacketRead:] + 72
    5   ProjectX                            0x001265b3 -[SFSIOHandler handlePacketData:] + 890
    6   ProjectX                            0x00127383 -[SFSIOHandler onDataRead:] + 594
    7   ProjectX                            0x0013fedb -[UDPManager udpc:didReceiveData:fromAddress:] + 238
    8   ProjectX                            0x0013ea11 -[UDPController _readData] + 524
    9   ProjectX                            0x0013ee53 SocketReadCallback + 102
    10  CoreFoundation                      0x35d752ef __CFSocketPerformV0 + 638
    11  CoreFoundation                      0x35d72ad3 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
    12  CoreFoundation                      0x35d72335 __CFRunLoopDoSources0 + 364
    13  CoreFoundation                      0x35d71045 __CFRunLoopRun + 652
    14  CoreFoundation                      0x35cf44a5 CFRunLoopRunSpecific + 300
    15  CoreFoundation                      0x35cf436d CFRunLoopRunInMode + 104
    16  GraphicsServices                    0x35a73439 GSEventRunModal + 136
    17  UIKit                               0x308cfe7d UIApplicationMain + 1080
    18  ProjectX                            0x00065903 main + 150
    19  ProjectX                            0x00065868 start + 40
)
2012-10-25 11:13:41.990 ProjectX[34804:707] *** Terminating app due to uncaught exception 'SFSCodecException', reason: 'Can't decode an SFSObject. Byte data is insufficient. Size: 0 byte(s)'
*** First throw call stack:
(0x35d9e88f 0x31717259 0x112ef3 0x127c15 0x12a135 0x1265b3 0x127383 0x13fedb 0x13ea11 0x13ee53 0x35d752ef 0x35d72ad3 0x35d72335 0x35d71045 0x35cf44a5 0x35cf436d 0x35a73439 0x308cfe7d 0x65903 0x65868)
terminate called throwing an exception(lldb)


[A51Integrated]

Typically this is cause by the client getting overwhelmed by messages. What happens, is that the SFS server can pound a client with messages and barely feel like it's working, but the client on the other hand, can only handle so much. Depending on how frequently you're sending messages to the client, the size of the messages, and how the client handles them will determine the client message capacity.

Remember, the best connection you'll get on a mobile device is with Wi-Fi, so you're already at a disadvantage in that the network connection is less than optimal. If you send a significant amount of data through that connection, TCP packets may start to get dropped and because they are TCP, they will be sent again until the entire TCP message is received. Most likely, this is what's happening and packets never make it to the client because the network connection is over capacity, experiencing too much lag, or dropping out altogether. You may want to try implementing UDP messages (through extensions) depending on what type of message you're sending. If the information being sent is non-critical, UDP may be a better option since verification of receipt does not occur.

Also, look at your messaging architecture and try and combine data into a single object as apposed to sending multiple messages. This will also reduce the number of messages the client needs to handle.

[Fellow]

We are still running into the same problem. If we want to catch this error where would we place our try catch blocks?

Is there a way to gracefully catch errors that are thrown by smartfox? Currently our application crashes completly when smartfox throws an error because the exception goes all the way to our main class without being caught higher up.

Thanks

[A51Integrated]

Let me look into this.

[Fellow]

Ok thanks. I've reading the documentation as well but I couldn't find anything about catching an exception that is thrown by the smartfox library.

[A51Integrated]

Have you tried something like:

Code: Select all

#import "SFSCodecException.h"

@try {
    // do something that might throw an exception
}
@catch (SFSCodecException *ex) {
    // deal with the exception
}
@finally {
    // optional block of clean-up code
    // executed whether or not an exception occurred
}

[Fellow]

Well that is just the general try catch structure. The question is more, where do you place that code?
Is the main the only place where you can catch that error? Isn't it too late then already?

[A51Integrated]

Try it in your main around the SmartFox2XClient instance and let me know. Although I think you may be right. By the time the exception is thrown, it would have killed the chance of capturing the event outside of the API.

Let me do some tests on this end and see what I can find.

[A51Integrated]

OK. From Apple: http://developer.apple.com/library/ios/ ... works.html#//apple_ref/doc/uid/TP40009045-SW1

The Cocoa frameworks are generally not exception-safe. The general pattern is that exceptions are reserved for programmer error only, and the program catching such an exception should quit soon afterwards.

So in theory, when an exception is thrown like this, the app should quit (which it does). Catching these errors and continuing may cause undesirable affects. However, there is a way to catch the error from the Main class, the trick is to not quit the application.

Code: Select all

#import <UIKit/UIKit.h>
#import "SFSCodecException.h"

int main(int argc, char *argv[]) {
   
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   
int result = 0   ;
   
@try {
    result = UIApplicationMain(argc, argv, nil, nil);
}
@catch (SFSCodecException *ex) {
    NSLog(@"%@", ex);
}
@finally {
    NSLog(@"This always happens.");
    result += 2;
}
   
[pool release];
return result;

}

Although this is bad practice and I would recommend not to use it.

[Fellow]

Ok, thanks.

We get that error quiet a lot when we are developing our game and because we use the debug it crashes constantly.
It doesn't crash when we make a release build (just like Apple says in that documentation "reserved for programmer error only").

So I guess there is no solution for this problem since the crashing happens in smartfox.

[A51Integrated]

It's not really SFS where the error happens - that's where it's thrown. What the API is trying to do is read a packet, and because the packet is incomplete, it throws the exception. So it works as expected.

[Fellow]

Our QC team is currently testing our app intensively and we are seeing that 85% of the crashes are happening because of an exception thrown by the smartfox library.
We are seeing 2 different types of exceptions:

Type 1: Can't decode an SFSObject. Byte data is insufficient. Size: 0 byte(s)
(happens 40% of the crashes)

Code: Select all

Exception Type:  SIGABRT
Exception Codes: #0 at 0x3bfef350
Crashed Thread:  0

Application Specific Information:
*** Terminating app due to uncaught exception 'SFSCodecException', reason: 'Can't decode an SFSObject. Byte data is insufficient. Size: 0 byte(s)'

Last Exception Backtrace:
0   CoreFoundation                      0x000c22a3 __exceptionPreprocess + 163
1   libobjc.A.dylib                     0x3baf197f _objc_exception_throw + 31
2   MyAPP                           0x005f5a2b -[DefaultSFSDataSerializer binary2object:] (DefaultSFSDataSerializer.m:774)
3   MyAPP                           0x0060a74d +[SFSObject newFromBinaryData:] (SFSObject.m:41)
4   MyAPP                           0x0060cc6d -[SFSProtocolCodec onPacketRead:] (SFSProtocolCodec.m:89)
5   MyAPP                           0x006090eb -[SFSIOHandler handlePacketData:] (SFSIOHandler.m:92)
6   MyAPP                           0x00609ebb -[SFSIOHandler onDataRead:] (SFSIOHandler.m:234)
7   MyAPP                           0x005eaa69 -[BitSwarmClient stream:handleEvent:] (BitSwarmClient.m:479)
8   CoreFoundation                      0x0005f7cf _signalEventSync + 75
9   CoreFoundation                      0x00065623 _cfstream_solo_signalEventSync + 75
10  CoreFoundation                      0x0005f507 _CFStreamSignalEvent + 327
11  CFNetwork                           0x000aca8b CoreReadStreamCFStreamSupport::coreStreamReadEvent(__CoreReadStream*, unsigned long) + 99
12  CFNetwork                           0x000abc71 CoreReadStreamClient::coreStreamEventsAvailable(unsigned long) + 37
13  CFNetwork                           0x000ae365 CoreStreamBase::_callClientNow() + 45
14  CFNetwork                           0x000ae0f9 CoreStreamBase::_streamSetEventAndScheduleDelivery(unsigned long, unsigned char) + 89
15  CFNetwork                           0x000ae4ff CoreStreamBase::_streamInterface_SignalEvent(unsigned long, CFStreamError const*) + 35
16  CFNetwork                           0x00007a15 SocketStream::dispatchSignalFromSocketCallbackUnlocked(SocketStreamSignalHolder*) + 41
17  CFNetwork                           0x0001cb57 SocketStream::socketCallback(__CFSocket*, unsigned long, __CFData const*, void const*) + 135
18  CFNetwork                           0x0001cab3 SocketStream::_SocketCallBack_stream(__CFSocket*, unsigned long, __CFData const*, void const*, void*) + 75
19  CoreFoundation                      0x00099ebb __CFSocketPerformV0 + 699
20  CoreFoundation                      0x00097683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
21  CoreFoundation                      0x00096ee9 __CFRunLoopDoSources0 + 213
22  CoreFoundation                      0x00095cb7 __CFRunLoopRun + 647
23  CoreFoundation                      0x33bacebd _CFRunLoopRunSpecific + 357
24  CoreFoundation                      0x33bacd49 _CFRunLoopRunInMode + 105
25  GraphicsServices                    0x3775f2eb _GSEventRunModal + 75
26  UIKit                               0x35ac2301 _UIApplicationMain + 1121
27  MyAPP                           0x000038c5 main (main.m:15)
28  libdyld.dylib                       0x00001b20 start + 0

Type 2: Unexpected header byte: 49
(happens 60% of the crashes)

Code: Select all

Exception Type:  SIGABRT
Exception Codes: #0 at 0x3bfef350
Crashed Thread:  0

Application Specific Information:
*** Terminating app due to uncaught exception 'SFSException', reason: 'Unexpected header byte: 49'

Last Exception Backtrace:
0   CoreFoundation                      0x000c22a3 __exceptionPreprocess + 163
1   libobjc.A.dylib                     0x3baf197f _objc_exception_throw + 31
2   MyAPP                           0x00609b4b -[SFSIOHandler handleNewPacket:] (SFSIOHandler.m:200)
3   MyAPP                           0x00609dfb -[SFSIOHandler onDataRead:] (SFSIOHandler.m:225)
4   MyAPP                           0x00622a13 -[UDPManager udpc:didReceiveData:fromAddress:] (UDPManager.m:161)
5   MyAPP                           0x00621549 -[UDPController _readData] (UDPController.m:127)
6   MyAPP                           0x0062198b SocketReadCallback (UDPController.m:150)
7   CoreFoundation                      0x00099ebb __CFSocketPerformV0 + 699
8   CoreFoundation                      0x00097683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
9   CoreFoundation                      0x00096ee9 __CFRunLoopDoSources0 + 213
10  CoreFoundation                      0x00095cb7 __CFRunLoopRun + 647
11  CoreFoundation                      0x33bacebd _CFRunLoopRunSpecific + 357
12  CoreFoundation                      0x33bacd49 _CFRunLoopRunInMode + 105
13  GraphicsServices                    0x3775f2eb _GSEventRunModal + 75
14  UIKit                               0x35ac2301 _UIApplicationMain + 1121
15  MyAPP                           0x000038c5 main (main.m:15)
16  libdyld.dylib                       0x00001b20 start + 0

Solution?

1. How can we make sure that these errors are not happening anymore? If these exceptions are forcing us to quit the application, we want to know why we are getting these errors.
2. These crashes happen very random and there doesn't seem to be a pattern to make it crash. How can we reproduce these errors? How can we get more information about these exceptions?
3. How can we avoid this crash and what do you suggest that we need to examine and test?

Previous assumption that these crashes only were happening during debugging was false. It also happens in the release builds.

Thanks,
Jonas

PS: Do you provide more in depth support for customers?

[A51Integrated]

1. How can we make sure that these errors are not happening anymore? If these exceptions are forcing us to quit the application, we want to know why we are getting these errors.

As mentioned above, it's a volume issue. The device simply can't handle the amount of communications back and forth. You're going to have to look into reducing/compressing/optimizing your messages in your app. Think of it like a highway with a serious traffic jam. No matter what you do to your car, it will still be stuck in traffic. You have to reduce traffic in order to travel at 100km/h.

2. These crashes happen very random and there doesn't seem to be a pattern to make it crash. How can we reproduce these errors? How can we get more information about these exceptions?

Because it's related to "overloading" the client, to reproduce, just hammer the client with messages.

3. How can we avoid this crash and what do you suggest that we need to examine and test?

reduce/compress/optimize

Do you provide more in depth support for customers?

Yes. Paid, but in this circumstance I'm not sure you'll benefit from it. Can you describe the structure of your typical messages and how frequently they are being sent/received?

[Fellow]

Thanks for the quick reply! Great service!

We'll do some testing this week and we'll try to find a scenario where it always crashes.
We'll also give you some more details about how many messages are being sent and what there size are.

Thanks!
Jonas