Никак не могу разобраться. Пишу приложение, в котором несколько тредов работают с БД mysql через общее (разделяемое) подключение. Вроде бы выполнил все рекомендации из мануала mysql (той части, что про threaded client), но все равно как только какой-нибудь тред вторично(!!!) лезет в БД, приложение падает с segmentation fault. Т.е. по первому разу все треды выполняют запросы нормально, но как только какой-нибудь выполняет вторую задачу, требующую обращения к БД, все падает. Уменьшение числа рабочих тредов до 1 (т.е. базовый тред, ставящий задачи + 1 тред, обрабатывающий задачи) проблемы не решает. Как только убираю запрос к БД (все остальное остается, т.е. инициализация клиентской библиотеки БД, подключение к серверу БД и т.п не убираю), приложение работает нормально.
Куда копать уже не знаю, подскажите что-нибудь...
Забыл сказать, используются запросы STMT. Может дело в этом? В мануале про STMT + треды молчат. Еще приложение использует openSSL, но вряд ли он замешан в моих проблемах.
Исходники к сожалению дать не могу.
Помогите кто чем может :)
Спасибо.
пользуйтесь отладкой gdb :) Скорее всего проблема не в mysql библиотеке, или по крайней мере в последовательности вызовов mysql функций.P.S. Код может и не помог бы, если его много. Попробуй сделать прототип. Его и тестить легче, и запостить проблем меньше.
>пользуйтесь отладкой gdb :) Скорее всего проблема не в mysql библиотеке, или
>по крайней мере в последовательности вызовов mysql функций.А вы пробовали отлаживать треды с помощью gdb? gdb говорит, что у меня приложение в SSL_accept() падает :)))
Проблема скорее всего действительно не в mysql библиотеке, а в mysql документации. Точнее в ее отсутствии.
Если у кого-нибудь есть идеи, где можно посмотреть вразумительную реализацию многотредового клиента, ткните меня туда носом...>P.S. Код может и не помог бы, если его много. Попробуй сделать
>прототип. Его и тестить легче, и запостить проблем меньше.Да по сути как раз прототип и отлаживаю, по крайней мере упростил по максимуму. Но даже в таком виде код достаточно большой.
>А вы пробовали отлаживать треды с помощью gdb? gdb говорит, что у
>меня приложение в SSL_accept() падает :)))если стек не порушен - нормально можно отладить. Кстати, если ругается на SSL, можно рекомендовать пока отключить его. По крайней мере на время отладки.
>Проблема скорее всего действительно не в mysql библиотеке, а в mysql документации.
>Точнее в ее отсутствии.Там вроде все нормально с документацией. Может быть имеет смысл включить протокол передачи , который появился в версии 4.1.x между сервером и клиентом (ищи строку "41" в имени опции). Факт, что старый протокол точно не умеет работать с двумя паралелльными запросами, а особенно с двумя выборками. Но и с новым протоколом тоже не факт, что сумеет (он кстати, по умолчанию выключен).
>Если у кого-нибудь есть идеи, где можно посмотреть вразумительную реализацию многотредового клиента,
>ткните меня туда носом...Обычно люди делают столько mysql коннектов, сколько потоков, и работают с ними без конкуренции в потоках. Опции для потоков нужны при работе с библиотекой mysqld, а не с mysqlclient.
>>А вы пробовали отлаживать треды с помощью gdb? gdb говорит, что у
>>меня приложение в SSL_accept() падает :)))
>
>если стек не порушен - нормально можно отладить. Кстати, если ругается на
>SSL, можно рекомендовать пока отключить его. По крайней мере на время
>отладки.
Да в том то и дело, что SSL ни при чем. Просто насколько я понял gdb не умеет отлаживать многотредовые приложения, вот и выдает, дурилка, что процесс упал на accept(), который просто ждал очередного клиента. А реальная причина в другом треде.>>Проблема скорее всего действительно не в mysql библиотеке, а в mysql документации.
>>Точнее в ее отсутствии.
>
>Там вроде все нормально с документацией. Может быть имеет смысл включить протокол
>передачи , который появился в версии 4.1.x между сервером
>и клиентом (ищи строку "41" в имени опции). Факт, что старый
>протокол точно не умеет работать с двумя паралелльными запросами, а особенно
>с двумя выборками. Но и с новым протоколом тоже не факт,
>что сумеет (он кстати, по умолчанию выключен).
Да новый протокол вроде тоже не умеет (я ковыряюсь в mysql 5.0.27). Обходится это блокировкой мьютекса на момент выполнения кода от mysql_stmt_execute() до mysql_stmt_store_result(), т.е. реально по протоколу перегоняется не более одного запроса одновременно.>>Если у кого-нибудь есть идеи, где можно посмотреть вразумительную реализацию многотредового клиента,
>>ткните меня туда носом...
>
>Обычно люди делают столько mysql коннектов, сколько потоков, и работают с ними
>без конкуренции в потоках. Опции для потоков нужны при работе с
>библиотекой mysqld, а не с mysqlclient.
Да наверное так и буду делать, лишнее соединение впринципе ресурсов много не жрет. Тем более, что они открываются при загрузке приложения и держатся открытыми постоянно.
Я пытался использовать модель с конкурирующими на одном соединении тредами потому что во первых не разобрался с производительностью, а во вторых хотел упростить процедуру переподключения к серверу БД в случае ошибок и потери коннекта. Сейчас пробую модель в которой каждый "сам за себя", т.е. каждый тред самостоятельно держит собственное подключение. Теоретически это даст прирост производительности, т.к. треды не будут простаивать, ожидая освобождение ресурсов для работы с БД.А вообще спасибо, я правда уже до всего этого сам дошел, но теперь есть уверенность, что иду в правильном направлении. Может еще какие идеи есть? Выслушаю с благодарностью.
Что то никак я не могу победить проблему... Приложение падает на mysql_stmt_execute(), причем через раз. Бывает удачно запустится и не падает вообще, бывает после второго вызова падает. Я в отчаянии...
info threads
thread N
bt