bad file descriptor
работаю с сокетами под убунту
когда вызывается функция
send(sock, get, strlen(get), 0);
perror(«errno»); выводит на коноль следующее:
errno: Bad file descriptor
с чем это может быть связано??
Системный вызов epoll_ctl: Bad file descriptor
Программа выдает epoll_ctl: Bad file descriptor. Помогите разобраться что не так делаю int fd.
Ошибка при линковке «fatal bad object file record in module near module file offset 0x0000032D»
Добрый вечер, форумчане:) Обращаюсь к знающим ассемблер,а именно TASM. Код программы есть. После.
вот скажи, какой тайный смысл в этой строке? 
niXman, а как надо писать?
Добавлено через 8 минут
niXman, perror понял как писать
КРАТКАЯ СВОДКА
#include
#include
int socket(int domain, int type, int protocol);
ОПИСАНИЕ
socket создает оконечную точку для коммуникации и возвращает её дескриптор.
Сокет имеет указанный тип, type, задающий семантику коммуникации. В настоящее время определены следующие типы:
SOCK_STREAM
Обеспечивает надежные, двунаправленные последовательные потоки байтов, с поддержкой соединений. Может также поддерживаться механизм вне-поточных данных.
SOCK_DGRAM
Обеспечивает датаграммы (ненадежные сообщения с ограниченной максимальной длиной, без поддержки соединения).
SOCK_SEQPACKET
Обеспечивает последовательный двунаправленный канал передачи датаграмм с поддержкой соединений; датаграммы имеют ограниченную максимальную длину; от
получателя требуется за один раз прочитать целый пакет.
SOCK_RAW
Обеспечивает доступ к низкоуровневому сетевому протоколу.
SOCK_RDM
Обеспечивает надежную доставку датаграмм без гарантии их последовательности.
SOCK_PACKET
Устарело и не должно использоваться в новых программах; см. packet(7).
Некоторые типы сокетов могут не быть реализованными в некоторых наборах протоколов; например, SOCK_SEQPACKET не реализовано в наборе AF_INET.
Сокеты типа SOCK_STREAM являются дуплексными потоками байт, похожими на трубы. Они не сохраняют границы между записями. Потоковый сокет должен быть в соединённом
состоянии перед тем, как по нему можно отсылать и принимать данные. Соединение с другим сокетом создается с помощью системного вызова connect(2). После соединения
данные можно передавать, используя системные вызовы read(2) и write(2), или какой-то из вариантов системных вызовов send(2) и recv(2). Когда сессия закончена,
выполняется close(2). Вне-поточные данные могут передаваться, как описано в send(2), а приниматься, как описано в recv(2).
Коммуникационные протоколы, которые реализуют SOCK_STREAM, следят, чтобы данные не были потеряны или продублированы. Если у корреспондента имеется место в буфере,
но очередная порция данных не может быть передана за разумное время, то соединение считается мертвым. Когда на сокете включен флаг SO_KEEPALIVE, протокол каким-либо
способом проверяет, что другая сторона ещё жива. Сигнал SIGPIPE появляется, если процесс посылает или принимает данные, пользуясь разорванным потоком; это приводит
к тому, что неопытные процессы, не обрабатывающие сигнал, завершаются. Сокеты SOCK_SEQPACKET используют те же самые системные вызовы, что и сокеты SOCK_STREAM.
Единственное отличие в том, что вызовы read(2) вернут только запрошенное количество данных, а остаток прибывшего пакета будет отброшен. Границы между сообщениями во
входящих датаграммах сохраняются.
Сокеты SOCK_DGRAM и SOCK_RAW позволяют посылать датаграммы корреспондентам, заданным при вызове send(2). Датаграммы обычно принимаются с помощью вызова recvfrom(2),
который возвращает следующую датаграмму с соответствующим обратным адресом.
Системный вызов fcntl(2) с аргументом F_SETOWN может использоваться, чтобы задать группу процессов, которая будет получать сигнал SIGURG, когда прибывают
вне-поточные данные или сигнал SIGPIPE, когда соединение типа SOCK_STREAM неожиданно обрывается. Этот вызов также можно использовать, чтобы задать процесс или
группу процессов, которые получают асинхронные уведомления о вводе-выводе с помощью SIGIO. Использование F_SETOWN эквивалентно использованию ioctl(2) с аргументом
SIOSETOWN.
Когда сеть сообщает протоколу об ошибке (в случае IP, например, используя ICMP-сообщение), то для сокета устанавливается флаг ожидающей ошибки. Следующая операция с
этим сокетом вернет код ожидающей ошибки. Для некоторых протоколов можно разрешить для конкретного сокета очередь ошибок, чтобы получить детальную информацию об
ошибке; см. IP_RECVERR в ip(7).
ОШИБКИ
EPROTONOSUPPORT
Тип протокола или указанный протокол не поддерживаются в этом домене.
ENFILE Ядру не хватило памяти, чтобы создать новый сокет.
EMFILE Переполнение таблицы файлов процесса.
EACCES Не разрешено создание сокета указанного типа и/или протокола.
ENOBUFS или ENOMEM
Недостаточно памяти. Сокет не может быть создан, пока не освободится память.
EINVAL Неизвестный протокол, или недоступный набор протоколов.
Другие ошибки могут быть сгенерированы нижележащими модулями протоколов.
СООТВЕТСТВИЕ СТАНДАРТАМ
4.4BSD (системный вызов socket появился в 4.2BSD). Обычно переносимо с/на не-BSD системы, имеющие реализацию сокетов BSD (включая варианты System V).
ЗАМЕЧАНИЕ
Для наборов протоколов под BSD 4.* используются константы PF_UNIX, PF_INET и т. д., тогда как AF_UNIX и т. п. используются для указания семьи адресов. Однако же,
страница руководства из BSD обещает: «Вообще, набор протоколов совпадает с семьей адресов», и в последующих стандартах везде используется AF_*.
СМОТРИ ТАКЖЕ
accept(2), bind(2), connect(2), getprotoent(3), getsockname(2), getsockopt(2), ioctl(2), listen(2), read(2), recv(2), select(2), send(2), shutdown(2), socketpair(2),
write(2)
Что такое файловый дескриптор простыми словами
Файловый дескриптор — это неотрицательное число, которое является идентификатором потока ввода-вывода. Дескриптор может быть связан с файлом, каталогом, сокетом.
Например, когда вы открываете или создаете новый файл, операционная система формирует для себя запись для представления этого файла и хранения информации о нем. У каждого файла индивидуальный файловый дескриптор Linux. Открыли 100 файлов — где-то в ядре появились 100 записей, представленных целыми числами.
Как файлы получают дескрипторы
Обычно файловые дескрипторы выделяются последовательно. Есть пул свободных номеров. Когда вы создаете новый файл или открываете существующий, ему присваивается номер. Следующий файл получает очередной номер — например, 101, 102, 103 и так далее.
Дескриптор для каждого процесса является уникальным. Но есть три жестко закрепленных индекса — это первые три номера (0, 1, 2).
Когда вы завершаете работу с файлом, присвоенный ему дескриптор освобождается и возвращается в пул свободных номеров. Он снова доступен для выделения под новый файл. 
В Unix-подобных системах файловые дескрипторы могут относиться к любому типу файлов Unix: обычным файлам, каталогам, блочным и символьным устройствам, сокетам домена, именованным каналам. Дескрипторы также могут относиться к объектам, которые не существуют в файловой системе: анонимным каналам и сетевым сокетам.
Понятием «файловый дескриптор» оперируют и в языках программирования. Например, в Python функция os.open(path, flags, mode=0o777, *, dir_fd=None) открывает путь к файлу path, добавляет флаги и режим, а также возвращает дескриптор для вновь открытого файла. Начиная с версии 3.4 файловые дескрипторы в дочернем процессе Python не наследуются. В Unix они закрываются в дочерних процессах при выполнении новой программы.
Для чего нужны файловые дескрипторы
Чтобы оценить важность файловых дескрипторов, нужно разобраться, как работает файловая система.
Когда нужно выполнить ввод или вывод, процесс через системный вызов передает ядру дескриптор нужного файла. Ядро обращается к файлу от имени процесса. При этом у самого процесса нет доступа к файлу или таблице индексных дескрипторов.
Что такое плохой файловый дескриптор
Это ошибка, которая может возникнуть в многопоточных приложениях, — Bad file descriptor. Чтобы исправить ее, нужно найти код, который закрывает один и тот же дескриптор файла. Может произойти и другая ситуация — например, один поток уже закрыл файл, а другой поток пытается получить к нему доступ.
В однопоточных приложениях такая проблема обычно не возникает.
Что можно делать с файловыми дескрипторами
Файловые дескрипторы можно использовать для исправления ошибок. Например, если на диске нет свободного места, но вы не видите файлы, которые занимают пространство, то можно посмотреть открытые дескрипторы. Это поможет понять, какое приложение заняло весь доступный объем.
Важно понимать, что если мы один раз открыли файл, и он получил файловый дескриптор, то мы можем взаимодействовать с ним дальше. Не имеет значения, что с этим файлом происходит. Его могут переименовать, удалить, могут изменить его владельца, отобрать права на запись и чтение. Если вы уже начали работать с файлом и знаете его дескриптор, то можете продолжать с ним работать.
Bad File Descriptor with Linux Socket write() Bad File Descriptor C
I have an interesting problem with write(2) function. PrepareResponseForSetCoordinates function causes bad file descriptor error on write.
Here is the line of error: perror(«ERROR writing to socket»); total output: ERROR writing to socket: Bad file descriptor
I am sure that I have established the connection because PrepareResponseForConnectionTest works like a charm.
Can you have any idea about the reason of the error?
When I use gcc as compiler there was no problem. After that because of using multiple new cpp sources I am using g++ as compiler and I have this error.
Here below my code:
Here below you can see the code which run without error:
Here is my InitializeConnection function and ConnectToServer function:
3 Answers 3
In general, when «Bad File Descriptor» is encountered, it means that the socket file descriptor you passed into the API is not valid, which has multiple possible reasons:
I had this error too, my problem was in some part of code I didn’t close file descriptor and in other part, I tried to open that file!! use close(fd) system call after you finished working on a file.
The value you have passed as the file descriptor is not valid. It is either negative or does not represent a currently open file or socket.
So you have either closed the socket before calling write() or you have corrupted the value of ‘sockfd’ somewhere in your code.
[Errno 9] Bad File Descriptor Python Solved
Before jumping right into the content directly, it’s essential to analyze the topics by asking some What and How questions. What is a Bad file descriptor error in Python? How do they occur? What are the ways that can help in solving this kind of errors? When we answer these questions, we can eventually understand the essence of this content by the end of this article.
When you don’t allow the code to perform the functions related to the file descriptors and the methods used, a Bad File Descriptor Error arises in Python, indicating the wrong way of implementing the code.
Kicking start with the basics always helps in understanding the core of the subject and hence assists in finding solutions to the most complex problems ever.
Cause of Errors Python
It’s salient to know that only by encountering many errors in code will you be highly proficient in the specific programming language. When you come across a new error, you try to detect where that error appeared from. Eventually, you start researching how to rectify the mistake.
There are even high chances of you exploring more and achieving various easier ways to apply the code better. At last, you will end up observing that your skills in the concept and knowledge about the same had grown vast.
Errors ought to occur in any possible programming language. In Python, errors generally occur when a particular code segment is not in compliance with the advised usage. Various errors are commonly faced by programmers, which include indentation, syntax, etc.
Rectifying these errors is no big deal when you review your code thoroughly. Have a complete understanding of the concepts and know enough about the right syntax to be used in the code.
What are File Descriptors in Python?
In Python, file descriptors are integers(positive) that identify the kernel’s open files kept in a table of files. They are generally non-negative values.
If found to be negative, that indicates error or a “no value” condition. They assist in performing various functions related to files. Descriptors, in general, are a unique way that Python follows to manage attributes.
They mainly help in accessing files, other input/output devices like network sockets or pipes.
File descriptors do perform various operations. They include:
The procedures mentioned above are elementary, and it’s important to know that file descriptors perform many more significant operations following the concept.
Understanding [Errno 9] Bad File Descriptor Error in Python
Have you encountered the following error message when you run your Python code when defining file directories or similar ones?
When you don’t allow the code to perform the functions related to the file descriptors and the methods used, these kinds of issues arise, indicating the wrong way of implementing the code.
Let’s understand this with an example:
The below image shows a code with a bad file descriptor error in the Python shell.
In the above code, the del file will delete the reference of the file object specified. Now, as per the code written, the close function was not called. This forces the destructor to close the file. As this resulted in closing a file that wasn’t open in the first place, OS throws an error – Bad file descriptor.
Best Ways to Solve from [Errno 9] Bad File Descriptor in Python
[Errno 9] Bad File Descriptor in Python Socket Module
Another main area in which this error is seen is in the Python socket – Socket error Bad file descriptor. When dealing with this kind of program, you can notice that you will find a Bad file descriptor error message is seen along with some issues in opening/closing or accessing the socket.
You can tackle this error by finding the right method of executing the function through the prescribed way of performing the function in accordance with the file descriptor.
One common thing that you can notice while handling errors in Python in relevance to files and file descriptors is that many of us fail to follow and implement the proper functions of the file descriptors defined in the code to perform the operations.
In addition to the above-discussed problems, this issue occurs while executing simple print statements too. You should focus on knowing if your specific file descriptors are available in the console that you are running.
This might seem simple when phrased but can cause a huge trauma to the programmer who has invested hours in writing the code. First, make sure that the specifies file descriptors are available in the console in which you run your program.
How to solve Bad File Descriptor in Python Socket module?
One way of handling this error is to calmly ignore the print statements and use alternative segments of code that serve a similar purpose.
Consider the following code –
This error is caused when you specify a function to get executed when it has already completed doing the job. For instance, you order your code to close a file through your long lines of code. It shows an error like:
It means that the file defined in the program is already closed automatically while running the code. There lies no use in defining a separate method to perform the same task again.
FAQs Related to Bad File Descriptor Python Solved
When we try to perform an operation/activity on closed (non-opened) files, a bad file descriptor error is generated. During such an error, you should look for possibilities where your file may get closed in your code.
In python file descriptors are integers(positive) that do the job of identifying the open files kept in a table of files by the kernel. They are generally non-negative values (0, 1, or 2).
fcntl is a library in Python that controls the file and I/O on file descriptors.
Conclusion
Bad file descriptor mainly arises due to many factors that were discussed in brief above. The main fact is that they occur when the right functions do not perform in association with the file descriptors.
With clear analysis and better knowledge of the concept, one can easily detect these errors and transform the code into a successful one.
Что может вызвать «плохой дескриптор файла» в многопоточной среде?
Этот вопрос чем-то похож на Неверный дескриптор файла но это не одно и то же. Я знаю, что это «плохой вопрос» (возможно, «слишком локализованный»), но я не могу понять это, и теперь у меня нет никаких идей.
У меня есть менеджер потока, который запускает 75 других потоков. Каждый из этих потоков делает много вещей, поэтому я опишу только соответствующие.
пожалуйста, обратите внимание: если я запускаю только несколько потоков — например, 3, 5 или 10, эта ошибка не появляется! Это заставляет меня думать, что это какая-то проблема многопоточности, но, похоже, она не такова. И вы поймете почему в следующих разделах.
Итак, в следующих 2 случаях ИНОГДА Я получаю эту ошибку Bad file descriptor :
Ошибка появляется в TinyXML
Есть XML-файл, который нужен всем потокам. Все эти темы используют TinyXML разобрать файл. ВСЕ из этих тем используют этот файл READ-ONLY! (Я знаю, что это можно оптимизировать, но что угодно).
Итак, код, который вызывает Bad file descriptor ошибка заключается в следующем:
Это немного сложнее. Я удалил проверку возвращаемых значений, но они есть в моем реальном коде, так что это не проблема
Извините за длинный вопрос. Есть идеи?
Решение
Несколько слов о понимании файловых дескрипторов:
Файлы являются глобальными ресурсами. Для этого используется (процессная) глобальная индексация: целочисленные значения, называемые дескрипторами файлов. Если поток открывает файл, этот открытый файл указывается индексом. Этот индекс уникален для процесса (не в потоке). Если файл закрыт, дескриптор файла (целочисленный индекс) больше не используется и может быть повторно использован процессом (и любым из его потоков).
Пример:
Любой поток в процессе 1-й вызов open() может вернуть 3, 2 может вернуть 4.
Если тогда 3 закрыто, третий вызов open() может вернуть 3 снова.
Если первый вызов выполняется потоком 1, второй — потоком 2, а третий — потоком 3, легко понять, что поток 1 не должен снова закрывать свой файловый дескриптор, так как значение 3, возможно, уже было переработано и использовать потоком 3, который будет пытаться получить доступ к недопустимому дескриптору файла, так как он мог быть закрыт 2-м (ошибочным) вызовом close() по теме 1. Хорошо? 😉
Попробуйте настроить пример кода и проверить / записать целочисленные значения, возвращаемые вызовами open() и назначены в качестве файловых дескрипторов, чтобы получить представление о том, как это работает.
Заметка:
Другие решения
Нужно искать код, который дважды закрывает один и тот же дескриптор файла.
В однопоточной программе это безобидная ошибка программирования, потому что вторая close() ничего не делает кроме возврата EBADF и много кода не удосуживается проверить close() возвращаемое значение в любом случае. Однако в многопоточной программе номер дескриптора закрытого дескриптора может быть распределен в другом потоке между двумя вызовами close() итак второе close() закроет несвязанный сокет из другого потока. Дальнейшее чтение и запись дескриптора другого потока приведет к ошибке «неверный дескриптор файла».
Если приложение является многопоточным, это может произойти, если один поток закрыл файл, а другой все еще пытается получить к нему доступ.
(потому что файловые дескрипторы, такие как адресное пространство, являются глобальными & общий для всех потоков процесса)
Вы могли бы использовать strace чтобы понять, что системные вызовы сделаны.
