asio, bad file descriptor(EBADF)
есть некоторый код, написанный с использованием asio, реализующий обмен некоторыми данными между клиентом и сервером.
- подключение к серверу
- обмен публичными ключами
- отсылает один пакет данных
- в основном находится в ожидании
проблема в том, что первые три пункта выполняются успешно, но после некоторого ожидания, при попытке послать серверу очередные данные, запись завершается с ошибкой «bad file descriptor»(EBADF)
попытки понять кто/кодга и почему закрывает сокет — ничего не дали. (сокет, вроде бы, ни клиент, ни сервер, не закрывают)
вопрос в том, есть ли какой-то софт, которым я могу мониторить состояние сокета извне?
ну и вообще, какие мысли?
Использование pipe в Python «Bad file descriptor»
Пытаюсь написать калькулятор, в котором все вычисления производятся в дочернем процессе, после чего он возвращает результат родительскому. Программа отрабатывает корректно один раз, а дальше-выдает ошибку «Bad file descriptor» В чем может быть причина? Все ломается как только добавляю цикл.
import os class Calculator: operations = ['+', '-', '*', '/', '.'] def add(self, a, b): return a + b def subtract(self, a, b): return a - b def multiply(self, a, b): return a * b def divide(self, a, b): return a / b def get_expression(self): user_input = input("Input the expression: op n1 n2 ") return bytes(user_input, encoding="UTF-8") def check_expression(self, expression): if len(expression) != 3 : return 0 if (expression[0] not in self.operations): return 0 else: return 1 def check_quit(self, user_input): user_input = user_input.decode("utf-8").split() if user_input[0] == '.': return 1 else: return 0 def find_result(self, user_input): user_input = user_input.decode("utf-8").split() operand = user_input[0] a = int(user_input[1]) b = int(user_input[2]) if operand == '+': return str(my_cl.add(a, b)).encode("utf-8") elif (operand == '-'): return str(my_cl.subtract(a, b)).encode("utf-8") elif (operand == '*'): return str(my_cl.multiply(a, b)).encode("utf-8") elif (operand == '/'): return str(my_cl.divide(a, b)).encode("utf-8") else: print("ERROR") my_cl = Calculator() r2, w2 = os.pipe() r1, w1 = os.pipe() pid = os.fork() while(1): if pid > 0: os.close(r2) os.close(w1) user_input = my_cl.get_expression() os.write(w2, user_input) print("Result:", os.read(r1, 100).decode("utf-8")) else: os.close(w2) os.close(r1) user_input = os.read(r2, 100) os.write(w1, my_cl.find_result(user_input)) Как победить bad file descriptor?
Пытаюсь сделать загрузочную флешку
3-мя программами пробовал ultraiso, rufus,RosaImageWriter
вылетает ошибка при записи bad file descriptor
контрольную сумму образа проверил, все ок
флешка в обычном режиме работает, в чем проблема не пойму
делаю загрузочную debian, linux mint — все ок, стартуют
только пытаюсь записать образ более 2gb (rosa linux, nitrux) — одна программа кидает ошибки
rufus вроде как пишет, но по окончанию с флешки стартануть никак лезут ошибки
флешка 16gb
- Вопрос задан более года назад
- 660 просмотров
3 комментария
Простой 3 комментария
Через управление дисками удали все разделы с флешки
И форматни там же
an @klekovkinandrey Автор вопроса
Drno, делал не раз и не одной программой
результат тот же
an, видимо все же что то с флешкой.
а если закинуть на неё 16гб инфы — не ругается?
Решения вопроса 1
Системный программист ^_^
Кажется, у вас паленая флешка, совсем не на 16 ГБ. Проверьте-ка её через H2testw
Ответ написан более года назад
Нравится 1 7 комментариев
an @klekovkinandrey Автор вопроса
проверил
не пойму
почему одни дистрибутивы без каких либо проблем пишутся на флешку
debian, linuxmint,bunsenlabs, crunchbang, manjaro, deepen
другие вообще ни в какую
linux rosa, nitrux
an @klekovkinandrey Автор вопроса
an, оо, а это винда так делает. потому что перезаписывая первый блок, вы затираете файловую систему и он перестает определяться системой как логический. поэтому запускайте Image Writer от админа и записывайте как PhysicalDrive0,а не просто G
an @klekovkinandrey Автор вопроса
15432, так запускаю от админа врайтер
G это буква диска, так определяет программа
а что это значит PhysicalDrive0 ? не совсем понимаю, как это выбрать
может стоит чем то другим записывать?
уже 4-мя прогами пробовал записать, безрезультатно (ultraiso,rufus,rosa image writer, winsetupefromusb)
запись проходит, вроде все ок, но флешка не стартует, просто курсор мигает
но флешка не стартует, просто курсор мигает
а это не флешка виновата, просто образ на вашей машине не запускается. почему — отдельный вопрос
может стоит чем то другим записывать?
записывайте тем, где
запись проходит, вроде все ок
и нет ошибок, как выше (bad file descriptor)
а что это значит PhysicalDrive0
от интерфейса программы зависит. в Windows есть несколько вариантов открыть один и тот же диск. Самое простое — по букве, можно даже с правами пользователя. Но может отвалиться, как у вас на скриншоте выше. Более экзотический вариант — по имени типа PhysicalDrive%, такое умеет, например, WinHex и некоторые другие редакторы. Наверняка Rufus тоже так открывает, но для красоты показывает диск по букве. Ну и самый экзотический — по полному пути, включающему номер USB порта, серийник флешки и т.д. Вряд ли найдется программа, что покажет такой полный путь среди вариантов открытия диска, но из программного кода — один из наиболее надежных способов найти вообще все диски.
an @klekovkinandrey Автор вопроса
an @klekovkinandrey Автор вопроса
15432, бред какой то
скачал balenaEtcher — и все пошло как по маслу
по какой причине остальные программы пишут через ж..у
хотя тем же ultraiso делал загрузочные debian, manjaro, linuxmint и все ок
а именно эти образы ни в какую
Ответы на вопрос 0
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Ubuntu
- +1 ещё
Система зависает при старте и выводит Kernel log, как перезапустить?
- 1 подписчик
- 12 дек. 2023
- 43 просмотра
Bad file descriptor что это
Есть сервер, который используя жаббероподобный протокол, обслуживает клиентов. Всё многопоточно, работает в режиме один поток — один клиент, блокирующий режим.
В теле цикла select, который следит за несколькими сокетами. один сокет к клиенту, другие — для внутренних целей (синхронизация и так дальше, используются unix сокеты).
все чтения/записи с/в сокет и другие блокирующие операции с сокетами (open, close. ) завернуты в TEMP_FAILURE_RETRY или делается проверка на errno==-1 и EINT. Это надо, так как приложение активно использует сигналы (Основную массу времени поток спит в select. А другие потоки посылают SIGUSR1/SIGUSR2 что бы пробудить поток (обычно это нужно только для удаления дубликатов — пользователи любят подключаться несколько раз — старые сессии удаляем). На другие сигналы (например SIGSERV) тоже повешены обработчики, которые находят поток-вредитель и завершают его.
И вот время от времени на клиентах при попытке сделать select возникает ошибка и errno возвращает Bad file descriptor. Интересно то, что возникает в нескольких потоках практически одновременно.
Интересуют методы выявления, какой сокет может быть плохим или как не допустить вообще такой ситуации, может есть какой-нибудь макрос/функция, что бы проверить, что сокет стал плохим.
Re: Ошибка Bad file descriptor
| От: | zaufi |
| Дата: | 17.02.09 10:46 |
| Оценка: |
Здравствуйте, OdesitVadim, Вы писали:
OV>Есть сервер, который используя жаббероподобный протокол, обслуживает клиентов. Всё многопоточно, работает в режиме один поток — один клиент, блокирующий режим.
?? чото я недопонял кто кого блокирует ??
OV>В теле цикла select, который следит за несколькими сокетами. один сокет к клиенту, другие — для внутренних целей (синхронизация и так дальше, используются unix сокеты).
OV>все чтения/записи с/в сокет и другие блокирующие операции с сокетами (open, close. ) завернуты в TEMP_FAILURE_RETRY или делается проверка на errno==-1 и EINT. Это надо, так как приложение активно использует сигналы (Основную массу времени поток спит в select. А другие потоки посылают SIGUSR1/SIGUSR2 что бы пробудить поток (обычно это нужно только для удаления дубликатов — пользователи любят подключаться несколько раз — старые сессии удаляем).
OMG! зачем так сложно то все? чем mutexы с conditionами не устраивают?
OV> На другие сигналы (например SIGSERV) тоже повешены обработчики, которые находят поток-вредитель и завершают его.
может SIGSEGV?? я конечно не знаю деталей твоего приложения но еси оно валицо по SIGSEGV нада найти баг и исправить его а не закрывать на это глаза делая вид что ничо страшного не происходит
OV>И вот время от времени на клиентах при попытке сделать select возникает ошибка и errno возвращает Bad file descriptor. Интересно то, что возникает в нескольких потоках практически одновременно.
OV>Интересуют методы выявления, какой сокет может быть плохим или как не допустить вообще такой ситуации, может есть какой-нибудь макрос/функция, что бы проверить, что сокет стал плохим.
сокет сам по себе «плохим» не становится. еси полоть закрытый (не существующий) сокет (дескриптор) получишь именна эту ошибку. погоняй свою прогу под valgrindом — imho многа нового узнаешь о поведении своей проги
Re[2]: Ошибка Bad file descriptor
| От: | OdesitVadim |
| Дата: | 17.02.09 14:59 |
| Оценка: |
Здравствуйте, zaufi, Вы писали:
Z>Здравствуйте, OdesitVadim, Вы писали:
OV>>Есть сервер, который используя жаббероподобный протокол, обслуживает клиентов. Всё многопоточно, работает в режиме один поток — один клиент, блокирующий режим.
Z>?? чото я недопонял кто кого блокирует ??
Сокеты в блокирующем режиме.
Z>OMG! зачем так сложно то все? чем mutexы с conditionами не устраивают?
Не все мютексами можно разрулить.
OV>> На другие сигналы (например SIGSERV) тоже повешены обработчики, которые находят поток-вредитель и завершают его.
Z>может SIGSEGV?? я конечно не знаю деталей твоего приложения но еси оно валицо по SIGSEGV нада найти баг и исправить его а не закрывать на это глаза делая вид что ничо страшного не происходит
Да, соскользнула рука. да эти события как неуловимые джо. Нет, нет. а потом хоп. но отрубать сразу всех клиентов как то не с руки.
Z>сокет сам по себе «плохим» не становится. еси полоть закрытый (не существующий) сокет (дескриптор) получишь именна эту ошибку. погоняй свою прогу под valgrindом — imho многа нового узнаешь о поведении своей проги
Да в том то дело, что если я сокет закрываю, то переменная для сокета получает значение -1. и кругом есть проверки на это -1.
под valgrindом гонял. часть отловил. Но к сожалению, он не всё может розрулить и основная масса сообщений — это либо баги валгринда, на их сайте написано «не обращать внимания», либо то, что даже непонятно, как устранить.
Но это не так важно, так как на отладочной машине я не могу воспроизвести ситуацию. А на продакшине — повторяется.
Чувствую, буду ещё жесче проверять сокеты.