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

Safari (Mac Only) crashes when using websocket #193

Closed
pbcomm opened this Issue Apr 23, 2011 · 36 comments

Comments

Projects
None yet
@pbcomm

pbcomm commented Apr 23, 2011

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

@3rd-Eden

This comment has been minimized.

Contributor

3rd-Eden commented Apr 23, 2011

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

@3rd-Eden

This comment has been minimized.

Contributor

3rd-Eden commented Apr 23, 2011

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.

@pbcomm

This comment has been minimized.

pbcomm commented Apr 23, 2011

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.
Thank you.

@pbcomm pbcomm closed this Apr 23, 2011

@3rd-Eden

This comment has been minimized.

Contributor

3rd-Eden commented Apr 23, 2011

One last note, just for the sake of completion: The bug can be found in Apples bugbase under Bug ID# 8244376. This bug is not present in the latest Webkit builds or in google chrome. So if you have suffer from this bug, and can't disable the Auto Proxy Discovery option you can use those browsers instead :)

@dvv

This comment has been minimized.

Contributor

dvv commented Jun 17, 2011

This issue is true for Safari for Windows too. Please, update the issue title.

@NuckChorris

This comment has been minimized.

NuckChorris commented Sep 4, 2011

Also happening on Safari Mobile over 3G, I'm assuming that acts as a proxy.

@3rd-Eden

This comment has been minimized.

Contributor

3rd-Eden commented Sep 4, 2011

What IOS version are you running? Also which phone ? Iphone 1, 3gs, 4 or 5 ;)?

On 4 sep. 2011, at 02:05, NuckChorris wrote:

Also happening on Safari Mobile over 3G, I'm assuming that acts as a proxy.

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

@NuckChorris

This comment has been minimized.

NuckChorris commented Sep 4, 2011

iOS 4.3.5 on an iPhone 4 GSM

@CameronJ

This comment has been minimized.

CameronJ commented Dec 1, 2011

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.

@christopherobin

This comment has been minimized.

Contributor

christopherobin commented Dec 7, 2011

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.

@NuckChorris

This comment has been minimized.

NuckChorris commented Dec 7, 2011

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:

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.


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

@NuckChorris

This comment has been minimized.

NuckChorris commented Dec 8, 2011

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.

@3rd-Eden

This comment has been minimized.

Contributor

3rd-Eden commented Dec 8, 2011

@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?

@NuckChorris

This comment has been minimized.

NuckChorris commented Dec 8, 2011

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.

@Irrelon

This comment has been minimized.

Contributor

Irrelon commented Feb 26, 2012

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.

@rauchg

This comment has been minimized.

Contributor

rauchg commented Feb 26, 2012

I've been trying to reproduce this today. Hopefully the fix is not to "disable websockets for safari" :)

@Irrelon

This comment has been minimized.

Contributor

Irrelon commented Feb 26, 2012

:) 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!

@NuckChorris

This comment has been minimized.

NuckChorris commented Feb 26, 2012

Actually you don't even need to switch windows, it'll happen either way, in my experience.

@Irrelon

This comment has been minimized.

Contributor

Irrelon commented Feb 26, 2012

@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.

@Irrelon

This comment has been minimized.

Contributor

Irrelon commented Feb 26, 2012

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.

@Irrelon

This comment has been minimized.

Contributor

Irrelon commented Feb 26, 2012

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.

@NuckChorris

This comment has been minimized.

NuckChorris commented Feb 26, 2012

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?

@Irrelon

This comment has been minimized.

Contributor

Irrelon commented Feb 26, 2012

@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!

@mloughran

This comment has been minimized.

mloughran commented Mar 19, 2012

@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.

@3rd-Eden

This comment has been minimized.

Contributor

3rd-Eden commented Mar 19, 2012

@mloughran This is a different crash, this crash is triggered when you you call the new WebSocket constructor and are browsing the web through a HTTP proxy.

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))

@NuckChorris

This comment has been minimized.

NuckChorris commented Mar 19, 2012

Can somebody test on iOS? If nobody else wants to, I'll check on iOS 5.1 some time soon.

@chrisclark

This comment has been minimized.

chrisclark commented Mar 29, 2012

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.

@Irrelon

This comment has been minimized.

Contributor

Irrelon commented Mar 29, 2012

@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.

@jxpx777

This comment has been minimized.

jxpx777 commented Jul 27, 2012

I'd just like to add that this appears to still be an issue in Safari 6 just released with Mountain Lion.

@3rd-Eden

This comment has been minimized.

Contributor

3rd-Eden commented Jul 27, 2012

I Just tested it using Version 6.0 (8536.25) of Safari and set the auto proxy discovery on and I was unable
to reproduce this.

On Friday 27 July 2012 at 17:43, Jamie Phelps wrote:

I'd just like to add that this appears to still be an issue in Safari 6 just released with Mountain Lion.


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

@jxpx777

This comment has been minimized.

jxpx777 commented Jul 27, 2012

This is working for my team in reproducing it with our Safari extension for 1Password:

  • Open System Preferences
  • Click Network -> Advanced... -> Proxies
  • Check the "Auto Proxy Discovery" option
  • Click Ok
  • Click Apply
  • Open Safari
  • (optional) Restart your computer and check the "Restore Windows" option
  • When you restart, click the 1Password extension icon. SPLAT.

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.

@jxpx777

This comment has been minimized.

jxpx777 commented Jul 31, 2012

See also Daniel Jalkut's post about this issue.

@metral

This comment has been minimized.

metral commented Dec 2, 2013

This issue still exists with socket.io and safari on an iphone5

@ghost

This comment has been minimized.

ghost commented Dec 31, 2015

The same issue are present in iOS 9.2 with Phonegap/webview implementation.

@charles-passille-smartnets

This comment has been minimized.

charles-passille-smartnets commented Feb 7, 2017

Still an issue for me. ExpressJS/NodeJS & socket.io

@dineshselvam92

This comment has been minimized.

dineshselvam92 commented Aug 3, 2017

When Streaming audio through websocket it show an error message failed: Failed to send WebSocket frame. in ionic app, is there any solution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment