AFNetworking/NSURLConnection получает NSPOSIXErrorDomain Code=9 Операция не может быть завершена. Неверный файловый дескриптор

В моем приложении, которое использует AFNetworking/NSURLConnection для отправки запросов на сервер, я иногда (очень редко) вижу эту ошибку в блоке сбоя операции:

Error Domain=NSPOSIXErrorDomain Code=9 "The operation couldn’t be completed. Bad file descriptor"

На https://devforums.apple.com/message/278770#278770 есть ответ на аналогичный вопрос:

Это означает, что кто-то освободил файловые дескрипторы из-под NSURLConnection.

Но в своем собственном коде я никак не трогаю потоки файловых дескрипторов. Это просто запросы GET/POST.

Что может быть причиной этой проблемы?

Кто-нибудь сталкивался с этой ошибкой в ​​своих операциях AFNetworking?

Кроме того, как я могу намеренно закрыть этот дескриптор файла, если я действительно этого хочу? Ответ на этот вопрос поможет мне лучше понять проблему.


ios afnetworking nsurlconnection
person kolyuchiy    schedule 27.02.2014    source источник
comment
Привет, я только что начал получать ту же ошибку с одним из моих клиентов. Вы когда-нибудь добирались до сути проблемы?   -  person Daz Eddy    schedule 03.10.2014
comment
Нет, к сожалению. Я просто отношусь к ним как к любой другой сетевой ошибке.   -  person kolyuchiy    schedule 03.10.2014

Ответы (2)


arrow_upward
1
arrow_downward

Согласно этим Apple TechNote о многозадачности и работе в сети, вы можете получить EBADF (ошибка POSIX 9), если приложение приостановлено, а сокет восстановлен.

Примечание. Когда ваше приложение возобновляет выполнение, фактическая ошибка, возвращаемая сокетом, ресурсы которого были восстановлены, намеренно не указывается здесь, чтобы обеспечить возможность будущих уточнений. Однако во многих случаях ошибка будет EBADF, что, вероятно, не то, что вы ожидали! В обычных обстоятельствах EBADF означает, что приложение передало недопустимый файловый дескриптор системному вызову. Однако в случае сокета, ресурсы которого были восстановлены, это не означает, что дескриптор файла был недействительным, просто сокет больше нельзя использовать.

person user102008    schedule 29.01.2015

arrow_upward
2
arrow_downward

(Я не думаю, что это полный ответ, но я надеюсь, что он будет полезен и может быть превращен в него.)

Ошибка, которую вы смотрите на это EBADF. Он вернулся из работы с закрытым файлом. Но вы уже поняли это. :)

Предполагая, что вы не используете библиотеку stdio, я думаю, что вы сталкиваетесь с перевыпуском. По сути, вы передаете право собственности на файл чему-то, что затем его закрывает.

Вы должны обратить особое внимание на NSFileHandle, особенно чтобы увидеть, не вызываете ли вы или кто-либо другой initWithFileDescriptor:, copy файл и т. д. Это может привести к тому, что NSFileHandle станет владельцем дескриптора файла, что означает закрытие его, когда он освобождается.

Меньше смотрите на свой сетевой код и больше на то, как вы настраиваете файлы.

person Steven Fisher    schedule 27.02.2014
comment
Спасибо за ответ! Согласно моему коду, эта ошибка возникает непосредственно из соединения NSURLConnectionDelegate: didFailWithError: callback. Как любой из файлов, которые я открываю в своем приложении, может вызвать эту ошибку? - person kolyuchiy; 28.02.2014
comment
Файлы больше похожи на необработанные указатели, чем на объекты Objective-C, если это имеет для вас какое-то значение. Объектом можно владеть много раз, и каждый из этих флагов владения должен исчезнуть, прежде чем сам объект будет освобожден из памяти. Напротив, вам нужно закрыть дескриптор файла только один раз, чтобы он был закрыт. Вот почему мне интересно, имеют ли более одного объекта один и тот же дескриптор файла, и один из этих дескрипторов файла закрывается. - person Steven Fisher; 25.03.2014