Crash in Websocket A/B in the iOS Simulator #234
Comments
|
Same here |
|
Thanks for your report, @mSauvestre ! It looks like the bug is in the code we use to enable the codeless event binding editor in your application. You can work around this issue by disabling dynamic event binding in by defining the DISABLE_MIXPANEL_AB_DESIGNER preprocessor macro in the CocoaPod settings in your build. I've attached a screenshot that shows you where you'd want to do this, the key thing is to set this in the Pod settings, not in the build settings for your application. I've attached a screenshot you can use to find the spot for setting the directive.
|
|
Same here. Thing is, I'll probably forget what I've changed here in the Pods settings, something that my coworkers wouldn't expect. I worry that risk and appreciate a quick fix. |
|
Same here, getting constant crashes.. even without being attached to Xcode... I just open the app normally and mix panel is crashing it |
|
Hi @raulriera @kenn Is there any more info you can give me on the crash? Is it also in MPWebSocket.m:1714 ? I have a pull request #237 that I think should fix it, but I can't be sure without a reproducible crash. |
|
Hi @alex-hofsteede , no I am getting a different one... about the connection not being opened. I will paste more info on monday :) |
|
Yep,
|
|
Were you guys able to resolve this? I have been seeing something similar starting today. When I restart the app I start seeing this crash - |
|
Any update on this being cut? |
|
Version 2.7.3 fixes 2 potential crash bugs in the Websocket connection code. Can you verify that this fixes the issue you are seeing. |
|
I still have the Assertion failure in -[MPWebSocket send:] in version 2.7.3 |
|
Hi Please provide solution for this please. |
|
I have the same exact crash as you @srinivashb , did you ever get to solve it? |
|
Same here. App crashes constantly. Crash log |
|
Thanks @srinivashb , @orfdna , and @geevanattinad - would you confirm that you're seeing this in the most recent version of the library (Version 2.7.3)? |
|
@joeatwork indeed. I just installed it yesterday via cocoapods. |
|
Got it- thanks, @orfdna ! |
|
Yep, the version I'm using is 2.7.3 |
|
Also confirming that we're continuing to see this crash on iOS Simulator using mixpanel-iphone 2.7.3. |
|
thanks all - we're going to push a fix for this soon. thanks so much for your patience - I'll update this thread when the patch is out. |
|
Any status update on this? According to Crashlytics, we're seeing this crash on actual devices (not just the simulator). Not frequently, but sometimes. And in the simulator, I've seen it kill the app within a second or two of launch, several launches in a row, which makes it a rather serious concern. |
|
@dgatwood v2.7.4 Fixes a race condition that caused us to try and open a second websocket when one had already been opened. This definitely fixes the |
|
Upgraded to 2.7.4, and I'm still seeing the crash. As I understand it, this crash is usually caused by the delegate somehow getting deallocated while the socket is still open and attached to a run loop. In a quick skim of the code, it looks like the "socket prematurely closed" case (where a stream read returns -1) doesn't clean up, and relies on the dealloc code to clean up. I suspect there's a race condition between the socket reenabling its callbacks and the first two lines in dealloc where you clear the delegate, and if the callbacks get reenabled at just the right time (after the object starts to tear itself down and becomes invalid for new method calls, but before your code clears the delegate to prevent future method calls), you get a crash. If I'm right, then doing something like this might help: diff --git a/Mixpanel/MPWebSocket.m b/hss/ThirdPartyFrameworks/Mixpanel/MPWebSocket.m
--- a/Mixpanel/MPWebSocket.m
+++ b/Mixpanel/MPWebSocket.m
@@ -370,12 +370,8 @@ static __strong NSData *CRLFCRLF;
- (void)dealloc
{
- _inputStream.delegate = nil;
- _outputStream.delegate = nil;
-
- [_inputStream close];
- [_outputStream close];
-
+ [self _closeStream];
+
mp_dispatch_release(_workQueue);
_workQueue = NULL;
@@ -1059,6 +1055,24 @@ static const uint8_t MPPayloadLenMask = 0x7F;
});
}
+- (void)_closeStream
+{
+ @synchronized(self) {
+ [_outputStream close];
+ [_inputStream close];
+
+ for (NSArray *runLoop in [_scheduledRunloops copy]) {
+ [self unscheduleFromRunLoop:[runLoop objectAtIndex:0] forMode:[runLoop objectAtIndex:1]];
+ }
+
+ [_outputStream setDelegate:nil];
+ [_inputStream setDelegate:nil];
+
+ _inputStream = nil;
+ _outputStream = nil;
+ }
+}
+
- (void)_pumpWriting;
{
[self assertOnWorkQueue];
@@ -1067,6 +1081,7 @@ static const uint8_t MPPayloadLenMask = 0x7F;
if (dataLength - _outputBufferOffset > 0 && _outputStream.hasSpaceAvailable) {
NSInteger bytesWritten = [_outputStream write:((const uint8_t *)_outputBuffer.bytes + _outputBufferOffset) maxLength:(dataLength - _outputBufferOffset)];
if (bytesWritten == -1) {
+ [self _closeStream];
[self _failWithError:[NSError errorWithDomain:MPWebSocketErrorDomain code:2145 userInfo:[NSDictionary dictionaryWithObject:@"Error writing to stream" forKey:NSLocalizedDescriptionKey]]];
return;
}
@@ -1086,13 +1101,7 @@ static const uint8_t MPPayloadLenMask = 0x7F;
!_sentClose) {
_sentClose = YES;
- [_outputStream close];
- [_inputStream close];
-
-
- for (NSArray *runLoop in [_scheduledRunloops copy]) {
- [self unscheduleFromRunLoop:[runLoop objectAtIndex:0] forMode:[runLoop objectAtIndex:1]];
- }
+ [self _closeStream];
if (!_failed) {
[self _performDelegateBlock:^{
|
|
@dgatwood Are you able to give me any more info that would let me repro the crash? You seem to be able to get it to happen pretty reliably but I haven't been able to actually get it to happen yet. Also, if you want to submit that code as a PR, that would be awesome. |
|
Even with that change, I'm still getting a sporadic crash (in the iOS 7.1 simulator). I'm investigating further. |
|
Okay, after digging through the registers, it looks like CFSocketEnableCallBacks is somehow getting called to enable read callbacks on a nil socket. And I have no idea why our usage is triggering it so readily. It might have something to do with querying an MPTweakValue shortly after the app launches for the first time. What makes this hard to track down is that it isn't really all that reliable. It might crash two or three launches in a row, and then not crash again for half a day. Incidentally, I see that you're using a bunch of method names prefixed with an underscore. You might want to avoid that; some folks have reported app store rejections because of SocketRocket doing that: facebookincubator/SocketRocket#226 and your code looks to be based on that code. Also, interestingly enough, the only other instance of this type of crash I've seen involved SocketRocket. I'm wondering if they've done anything to fix it. |
|
I made some changes to make the class going away mid-use less likely by shifting the nil-out of the self-reference pointer to the last possible moment. I haven't seen any problems since then. Crossing my fingers. |
|
Almost three weeks of testing with those patches, we've seen no further crashes. Please review the patches. |
|
Yesterday, we released the first build of our app with those patches included. I think it is safe to say that the problem is fixed; we've seen zero Mixpanel-related crashes in the first day, which is about 3,000 fewer crashes than projected based on the pre-patch crash rate. :-) Unless, of course, this really occurred only in the simulator, in which case, who knows. |
|
Thanks @dgatwood, I will get these changes in master and released asap. |
|
Waiting on #262 review |
|
This will be resolved in the next release. |
|
Hey guys I am facing the same issue even after updating the mixpanel. I have installed 2.8.3 version in my project and it continuously crashing the app . Here is the crash report Thread 0:: Dispatch queue: com.apple.main-thread Thread 1:: Dispatch queue: com.apple.libdispatch-manager Thread 2: Thread 3:: com.apple.CFSocket.private Thread 4:: com.apple.NSURLConnectionLoader Thread 5: Thread 6:: DYMobileDeviceManager Thread 7: Thread 8: Thread 9: Thread 10:: com.apple.CoreAnimation.render-server Thread 11:: Dispatch queue: parsing queue Thread 12:: Dispatch queue: parsing queue Thread 13: Thread 14: |
|
Any temporary solution for this ? |
From a customer report
Starting a couple of days ago, I am getting very frequent crashes in MPWebSocket.m:1714 (iOS SDK) when running in the simulator with iOS version 7.0.X. The crash happens within a minute or so of running the app regardless of what I am doing. We have not seen this crash in the wild to date.
The crash is EXC_BAD_ACCESS, but the run loop (_runLoop) looks fine, so it's not clear what object was actually deallocated.
Here is the stack trace on the problem thread:
The text was updated successfully, but these errors were encountered: