Xcode 9 iOS 11 BoringSSL SSL_ERROR_ZERO_RETURN

Asked 13/12, 2017 at 21:3 Answered 1/3, 2019 at 9:29

I have a simple program HelloWorld running on iOS. The same code has been running fine for a long time. Recently, I notice that I get the below BoringSSL error when the program runs on my ipad connected to Xcode 9 on my Macbook. I don't see this error when I run the program in simulator. The iOS is 11.2. Xcode is 9.2.

My code has no reference to BoringSSL. However, it does use NSMutableURLRequest to make https call to a server. The call works fine and everything seems to work fine except the BoringSSL messages.

Is there a way the I can debug why the message comes up? HellowWorld[466:85961], what do those 2 numbers mean?

What does the message mean and how to avoid it?

2017-12-13 15:41:13.486047-0500 HellowWorld[466:85961] [BoringSSL] Function boringssl_session_errorlog: line 2871 [boringssl_session_read] SSL_ERROR_ZERO_RETURN(6): operation failed because the connection was cleanly shut down with a close_notify alert
2017-12-13 15:41:13.486363-0500 HellowWorld[466:85961] [BoringSSL] Function boringssl_session_errorlog: line 2871 [boringssl_session_read] SSL_ERROR_ZERO_RETURN(6): operation failed because the connection was cleanly shut down with a close_notify alert

Mohamedmohammad answered 13/12, 2017 at 21:3 Comment(12)

I have the same issue, did not find a solution yet, I'm using Alamofire with a network request and the same error/warning is showing – Encasement 13/12, 2017 at 21:53

A similar question here on SO listed this as a possible explanation: github.com/Homebrew/homebrew-core/issues/… – Phototube 13/12, 2017 at 21:55

Also have the same issue – Limitary 14/12, 2017 at 14:15

I have the same issue – Senlac 15/12, 2017 at 11:26

Same for me using the Alamofire AFNetworking api. It happens to me when my rest-api takes time to respond. Could it be an Alamo fire time out on slow server response? – Dongdonga 17/12, 2017 at 19:47

@Alex: same issue for me, but I don't use Alamofire, I simply use my own Swift networking code and a PHP backend. This happens with any kind of request, even if there's no time involved (if I only get "Hello" from the server, it happens anyway). In my case, the app crashes IF there's a contemporary Internet issue (eg. connection error due to broadband issues) – Okoka 18/12, 2017 at 11:44

I run into this problem too no idea why it happens. My API calls and all the HTTP stuff works as expected but this error gets printed sometimes. – Subordinate 19/12, 2017 at 15:30

From openssl documentation openssl.org/docs/manmaster/man3/SSL_get_error.html: "SSL_ERROR_ZERO_RETURN: The TLS/SSL connection has been closed. If the protocol version is SSL 3.0 or higher, this result code is returned only if a closure alert has occurred in the protocol, i.e. if the connection has been closed cleanly. Note that in this case SSL_ERROR_ZERO_RETURN does not necessarily indicate that the underlying transport has been closed." – Macomber 22/12, 2017 at 10:0

I found that the issue in my case was a problem with headers, on the api side there where empty spaces above or below <?php ?> tags and the headers weren't set correctly at the correct places where needed. – Encasement 2/1, 2018 at 9:26

Did you find a solution please? – Maser 18/1, 2018 at 12:2

same issue here. did you find the reason ? – Chet 28/1, 2018 at 21:44

No one replied about the 2 numbers: they are typically the process id and thread id or some connection identifier. So they will change at each run. It just allows to group error related error messages together. – Thornie 11/4, 2018 at 23:27

Is there a way the I can debug why the message comes up?

Yes, there is, and I'm a bit surprised it hadn't been mentioned yet.

CFNetwork handles the core of Foundation’s networking classes — It also has the (often overlooked) capability of detailed logging via the CFNETWORK_DIAGNOSTICS environment variable.

Programmatically enabling CFNetwork diagnostic logging:

setenv("CFNETWORK_DIAGNOSTICS", "3", 1);

It should be set to an integer value from 0 to 3, where 0 is off and higher numbers give progressively more logging. During normal development you can set this environment variable via Xcode’s scheme editor. When the app is run from Xcode, the CFNetwork log entries will appear in the debug console area (if not visible, choose View > Debug Area > Show Debug Area).

The environment variable should be placed right at the beginning of the app’s launch sequence. Normally putting this at the start of main is sufficient, but if you have C++ static initialisers that use CFNetwork you’ll have to put it before those.

Note: In Swift this code would go in main.swift. By default Swift apps don’t have a main.swift; “The Swift Programming Language” explains how to add one.
_{*Also note, in Swift remove the semi-colon at the end of the setenv.}

Setting the environment variable above should definitely help in determining where the issue is, or at the very least give you a starting point to begin diagnosing a somewhat vague error message.

↳ CFNetwork Diagnostic Logging

Additive answered 25/2, 2018 at 8:42 Comment(1)

Actually tried ´setenv("CFNETWORK_DIAGNOSTICS", "3", 1);´ and it bricked my iPhone 6+. So a word of warning: only set this through Xcode scheme editor....... And start with a gentle value such as "1". – Debouchment 30/5, 2018 at 16:15

I managed to fix the issue by adding the "App Transport Security Settings" key to the info.plist. Make sure that "Allow Arbitrary Loads" is set to "Yes".

Nutwood answered 26/10, 2018 at 9:13 Comment(2)

The "Allow Arbitary Loads" property is set to "Yes". But I'm still getting these errors. For some messed up reason, when my app tries to upload data to our server which is using an HTTPS address, it fails, and any subsequent nagivation or pull-to-refresh actions will freeze the app. Any ideas? – Infantilism 9/12, 2018 at 21:32

Perhaps if I whitelist my server address (my-server.com) in the plist file, it would work then .. ? – Infantilism 9/12, 2018 at 21:56

For those of you for whom the above methods did not work, this is what the problem was in my case:

I was sending a GET request with a JSON request body using Alamofire. I changed it to a GET request that contains the parameters as query parameters in the URL instead (along the lines of GET https://your-api.com/v1/request?param=value). Then it worked flawlessly.

Anting answered 1/3, 2019 at 9:29 Comment(0)

-1

I got a similar message when trying to use NSLog to post a very long list as it would post the list for a long time in the debug console then it so list part of the list followed by a few ... to show there was more that was not printed in the console, I fixed this (using OBJ-C) and adding this #define to my VC.m

#define NSLog(FORMAT, ...) printf("%s\n", [[NSString stringWithFormat:FORMAT, ##__VA_ARGS__] UTF8String]);

perhaps you can use something similar to your swift project.

Seducer answered 27/2, 2018 at 15:51 Comment(0)

Recommended topics

Hot tags