Safari (Mac Only) crashes when using websocket #193
Comments
|
Known issue, it's a bug in safari. I have already reported it and the apple engineers are working on it. To solve it, turn off auto proxy discovery in your network settings |
|
Small note: it's not a bug caused by socket.io, as every web socket connection will crash and there is no way to detect this. |
|
Haha, I have just discovered the same thing, however I though it's my companies proxy that was the issue. I guess it's all of them. Interesting that it only happens on mac. |
|
One last note, just for the sake of completion: The bug can be found in Apples bugbase under |
|
This issue is true for Safari for Windows too. Please, update the issue title. |
|
Also happening on Safari Mobile over 3G, I'm assuming that acts as a proxy. |
|
What IOS version are you running? Also which phone ? Iphone 1, 3gs, 4 or 5 ;)? On 4 sep. 2011, at 02:05, NuckChorris wrote:
|
|
iOS 4.3.5 on an iPhone 4 GSM |
|
I just noticed the same problem on iOS 5.1 (iPhone 4S). So I assume that Apple still has not fixed this one. After the page goes to the background (app hidden) or tab changes. Returning to the tab causes safari to crash. |
|
It's also the case on iOS 5.0 (iPad 2) using a Manual Proxy. As soon as the websocket is created Safari just crash. |
|
Perhaps it'd be smart to add a workaround in the meantime, by detecting iOS Safari and preventing WebSockets on there, just falling back to the other transports? On Dec 6, 2011, at 11:35 PM, Christophe Robinreply@reply.github.com wrote:
|
|
I think this issue needs to be reopened, since it's quite clearly a major issue that isn't getting solved any time soon, it needs a workaround patch. |
|
@NuckChorris The only possible work around is to disable WebSockets for every safari, ever. And that is not viable. There are no workarounds for this issue as it's not detectable. @guille opinions? |
|
I think this is a serious issue that deserves even the ugliest of hacks (like sniffing the UA string for browser version) Crashing any browsers is just unacceptable behavior. |
|
I was pulling my hair out trying to work out why my game was crashing on iOS. I'm using Facebook connect which effectively opens a new window (puts the game window in the background) and whilst typing my FB details I can see the server logs that my client (the game) disconnected. After doing the FB login it brings the game window back into focus and boom, Safari crashes. After I did a load of tests I managed to type my U&P into FB connect fast enough and sure enough if you come back to the window in time it won't crash Safari. This was all on both an iPhone 4S with iOS 5.0.1 and same for iPad2. I'm currently working on a fix and will post here if I can get it to work... have several hacks in mind. |
|
I've been trying to reproduce this today. Hopefully the fix is not to "disable websockets for safari" :) |
|
:) the easiest test is to get a socket.io connection to a simple node.js process and then open a new window on your iPhone... watch on the node.js process for the client to disconnect, then switch back to the original client window. That should produce the crash. As far as I'm concerned, disabling websockets for Safari is a total no-go... websockets are point-blank the most important thing since sliced bread! |
|
Actually you don't even need to switch windows, it'll happen either way, in my experience. |
|
@guille Is there a way to set the heartbeat interval & timeout for a specific socket at runtime? Just a guess at this point - gonna confirm in about 2 minutes but if we set the socket so it doesn't timeout and disconnect then the crash wont occur. My proposed hack at the moment would be to set the heartbeat to off, then keep track of heartbeats client-side. If we are in the background then the heartbeat wont be sent for a while and we can then disconnect the client socket and reconnect it... I think the crash is occurring because an invalid socket (closed socket) is attempting to be written to. I've got some iPhone crash logs that point in that direction. |
|
I can confirm that if you disable heartbeats in socket.io that the crash will no longer occur. I am thinking that a good fix will be in the socket.io heartbeat send on the client - detect the last time the send was run. Since it's on a timer such as every 20 seconds, if the method runs and detects that the last run time was higher than say... 22 seconds, then it knows that the page was in a background process and no JS was running and that it should drop the connection on the client and reconnect. This is the only way I can think of to solve this for the time being. |
|
By the way, further to my last message, the reason the crash occurs is because the heartbeat signal (or in fact any socket.io message) being sent from the client to the server is being sent when the actual connection has been closed by the server. The client is unaware of the closed connection and attempts to send a message as soon as the page comes back into focus on the device. At this point, since the socket doesn't exist the browser crashes. |
|
This doesn't explain why socket.io seems only to crash when there's a proxy or 3G network behind it. Could that be another, unrelated issue caused by servers en route which can't handle WebSockets? |
|
@NuckChorris I think you're right, actually although the issues are similar I think mine is different... I should probably open a new bug. I'm not using a proxy. Sorry for hijacking this thread! |
|
@guille @coolbloke1324 I spent some time digging into what looks like the same issue (Safari crashing when returning to a tab, not the 3G one which is mixed in here...) at Pusher, and since I got to the bottom of what's going on I thought I'd share the love ;) There's a simple workaround which I've written up at https://gist.github.com/2052006 - also reported to apple in the hope that this might be fixed properly. |
|
@mloughran This is a different crash, this crash is triggered when you you call the I have re-tested this a couple days ago, and it seems to be resolved with the latest version of Safari (Version 5.1.4 (7534.54.16)) |
|
Can somebody test on iOS? If nobody else wants to, I'll check on iOS 5.1 some time soon. |
|
I was also pulling my hair out, trying to figure out why my mobile web app was crashing in mobile safari (but not Android) when it went off to log via Facebook. Just like coolbloke I narrowed it down to the websocket connection. The fix in my situation was quite easy - whenever a user hits the Facebook login button, I first tear down all websocket connections and unsubscribe from any PubSub channels prior to calling out to Facebook. When the FB auth returns, I reopen the socket and resubscribe. Easy enough and works like a charm! But good god was this a painful issue to track down. |
|
@chrisclark Totally. It's crazy that Safari does that! The worst thing is that debugging via mobile is SUCH a pain it's untrue. If it was desktop based we'd find the bug in seconds. |
|
I'd just like to add that this appears to still be an issue in Safari 6 just released with Mountain Lion. |
|
I Just tested it using Version 6.0 (8536.25) of Safari and set the auto proxy discovery on and I was unable On Friday 27 July 2012 at 17:43, Jamie Phelps wrote:
|
|
This is working for my team in reproducing it with our Safari extension for 1Password:
From there on out, it should consistenly crash at each Safari launch. pusher.com seems to be having this problem as well. I've contacted them to see if they're able to reproduce. |
|
See also Daniel Jalkut's post about this issue. |
|
This issue still exists with socket.io and safari on an iphone5 |
|
The same issue are present in iOS 9.2 with Phonegap/webview implementation. |
|
Still an issue for me. ExpressJS/NodeJS & socket.io |
|
When Streaming audio through websocket it show an error message failed: Failed to send WebSocket frame. in ionic app, is there any solution? |
|
Same issue :/ |
and others
I am using the very basic example listed on the website, not sending or receiving any messages, just connecting.
Connection is on 127.0.0.1:80
On connect Safari crashes with following:
Process: Safari [11081]
Path: /Applications/Safari.app/Contents/MacOS/Safari
Identifier: com.apple.Safari
Version: 5.0.5 (6533.21.1)
Build Info: WebBrowser-75332101~1
Code Type: X86-64 (Native)
Parent Process: launchd [238]
Date/Time: 2011-04-23 02:40:30.463 -0400
OS Version: Mac OS X 10.6.7 (10J869)
Report Version: 6
Interval Since Last Report: 140807 sec
Crashes Since Last Report: 20
Per-App Interval Since Last Report: 36857 sec
Per-App Crashes Since Last Report: 16
Anonymous UUID: 545FB01F-FF2E-4A16-9EFC-A8A538906A53
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x00007fff87e11c00 CFArrayGetCount + 80
1 com.apple.WebCore 0x00007fff82a3150b WebCore::SocketStreamHandle::chooseProxyFromArray(CFArray const) + 43
2 com.apple.WebCore 0x00007fff82cc6088 WebCore::SocketStreamHandle::pacExecutionCallbackMainThread(void) + 24
3 com.apple.JavaScriptCore 0x00007fff87bf6848 WTF::callOnMainThreadAndWait(void ()(void), void_) + 72
4 com.apple.WebCore 0x00007fff82cc5ec0 WebCore::SocketStreamHandle::pacExecutionCallback(void_, _CFArray const, _CFError) + 32
5 com.apple.CFNetwork 0x00007fff86cd167c executionContextPerform(void*) + 1079
6 com.apple.CoreFoundation 0x00007fff87e4f401 __CFRunLoopDoSources0 + 1361
7 com.apple.CoreFoundation 0x00007fff87e4d5f9 __CFRunLoopRun + 873
8 com.apple.CoreFoundation 0x00007fff87e4cdbf CFRunLoopRunSpecific + 575
9 com.apple.HIToolbox 0x00007fff830237ee RunCurrentEventLoopInMode + 333
10 com.apple.HIToolbox 0x00007fff83023551 ReceiveNextEventCommon + 148
11 com.apple.HIToolbox 0x00007fff830234ac BlockUntilNextEventMatchingListInMode + 59
12 com.apple.AppKit 0x00007fff80441e64 _DPSNextEvent + 718
13 com.apple.AppKit 0x00007fff804417a9 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 155
14 com.apple.Safari 0x0000000100015ff6 0x100000000 + 90102
15 com.apple.AppKit 0x00007fff8040748b -[NSApplication run] + 395
16 com.apple.AppKit 0x00007fff804001a8 NSApplicationMain + 364
17 com.apple.Safari 0x0000000100009f18 0x100000000 + 40728
The text was updated successfully, but these errors were encountered: