libmysql.DLL въпрос

здравейте, някой да е експериментирал малко повечко със libmysql.DLL ?

аз забелязах много кофти memory leaks, които съвсем определено идват от DLL-а.

значи схемата е следната - пристигат пакети на даден порт, след което за всеки пакет се стартира нов thread, който го обработва. thread-а използва функции от този DLL за SELECT, INSERT и UPDATE заявки.

всичко дотук добре. но залях софтуера за тест с по 30-ина пакета в секунда и забелязах огромни memory leaks.

по всичко вече личи, че това е проблем на DLL-a. същия софтуер го компилирам под LINUX (библиотеката си я бях разработил на LINUX и след това я портнах под Windows). но под LINUX смила над 200,000 пакета с милиони SQL заявки за да ги обработи без да се счупи и никакъв memory leak (за информация - window-ската версия също не crash-ва но затова пък на 30,000 пакет вече е заело 50 MB от паметта и продължава да гълта).

под Windows го компилирах с Borland C++ 5.5 Free Compiler. за мое най голямо учудване след като пробвах с MicroSHIT (т.е. Microsoft) Visual Sudio .NET се стигна до абсолютно същият ефект.

един малък прост тест само със стартиране на стотици threads в секунда, които да направят един прост INSERT в DB-то и да излязат показа, че проблема се корени някъде в този libmysql.DLL, защото при такава проста схема memory leak вече нямаше откъде аз да съм направил.

има ли някой повече ноу-хау по въпроса да даде малко акъл ...

или да пиша тоя libmysql.DLL боклук ?

чакайте, че пропуснах много важни неща

проблема съществува само в multi-threaded режим. ето още малко инфо.

компилирам със singlethreaded библиотеки на Borland - всичко бачка супер. single threaded безупречно, multithreaded - също - но с random crashes, щото карам със single threaded library-то и току се осерат например файловите или стрийм функциите щото не са thread-safe в тази компилация.

компилирам с multithreaded библиотеките - включвам в режим да обработва пакетите последователно - без стартиране на thread - идеално! никакъв memory leak. обръщам с много процеси - веднага си задръства паметта :(

абсолютен шит е дотук тоя libmysql.DLL ...

преработих си wrapper-ите за нови процеси да ползват CreateThread, _beginthread и _beginthreadex - всичкото дава един и същи ефект :(

Ползвам го ама по следната технология:
Имам CBuilder приложение, което използва dll'a за достъп до MySQL сървъра - така де направил съм си допълнителен dll, компоненти и т.н.
Е извикванията са ми в тред, ама един.
И нямам ликове - поне не съм установил до сега.
Имах в началото но си бяха чисто мои грешки.
ПП
Ползваш ли редовно
mysql_free_result

Bеer? Mоre?
Плацебото

да. имам един клас _MySQL - който е тестван вече месеци наред под LINUX и не дава абсолютно никакви leaks. всеки път щом трябва нова заявка, той автоматично си извиква mysql_free_result, ако е забравено и има такъв резултат от предното mysql_query(). дори и при унищожаването и излизането от видимост пак автоматично.

в single-threaded режим няма абсолютно никакви грижи. и най-забавния факт, който установих, е че ако си направя thread-pool със стартирани например 10 thread-а които нон-стоп пускат INSERT заявки и циклят проблема изчезва.

голям майтап! значи workaround-а за Windows ще е thread-pool!
mysql_thread_safe() ми връща 1, обаче този DLL въобще не е thread-safe!?!? както твърдят от mysql.com

между другото в клуб Бази данни, пише Salle.
А пича пише и за MySQL директно - в смисъл бачка за тях.
Та ако искаш питай го него, само му спомени версиите :)

Bеer? Mоre?
Плацебото

Не знам дали ще мога да ти помогна но .....
Аз ползвам ODBC драйвера на MySQL. Можеш да го изтеглиш от [линк] . След това можеш да работиш със стандартните ADO компоненти от C++ Builder-a или ADO.NET от Visual Studio - това последното съм го правил само със C#. Не съм имал никакви проблеми със ODBC драйвера. CodeGuard-a на ВСВ-то не ми е съобщил че има memory leaks.Лошото е, че ще трябва да го инсталираш на всички клиенти.

Можеш да включиш трасиране на всички ODBC API ф-ии от ODBC Data Sources Administration - tab Tracing. Кофти момента е, че ако не си писал с ODBC API ф-ии много трудно се разбира лога. М/у другото ОДБС драйвера си има и debug версия, която създава собствен лог, който е значително по пълен от този на стандартните ODBC драйвери. Включват се извикванията на всички API ф-ии + всички C ф-ии за работа с паметта използвани от тях.

Друг вариант - ZeosDBO от [линк] - безплатна, няма инсталация на ODBC драйвери, добра документация, компоненти за Делфи и ВСВ.

Да не би да забравяш някой CloseHandle(hThread) или _endthread(), _endthreadex() ?

Ама я си води сметка колко активни нишки имаш в него момент. Понеже нишките са малко памет поглъщащи:-) всяка си иска стек и по подразбиране е бая. Така ако имаш 50 активни нишки всичко си идва в ред. Можеш примерно като пускаш нова нишка да я хакаш със съвсем скромен размер на стека. Също ако съм прав явно излиза защо при една нишка всико е както трябва.

Ама това са само предположения...Просто се опитвам да помогна.

не забравям нито един CloseHandle() - брояча за активни threads и в LINUX компилацията и в Windows е една и съща. дори под Windows ги проверявам със WaitForSingleObject() преди да ги Close()-на, че да не омажа пейзажа за всеки случай.

проблема се оказа нещо съвсем конкретно с thread-safety на този DLL.

замислих се и аз за ODBC, но тук има едно условие - софтуерът беше за LINUX и сега има и версия за Windows (като LINUX версията му остава водещата при разработването). и от гледна точка на преносимост ODBC се оказа кофти choice.

всичко е OK с threads. проблема както отбелязах в един от отговорите по-горе е съвсем определно в DLL-а.

благодаря за помощта все пак.

благодаря за съвета. ще пусна един месидж, въпреки че направих workaround на проблема и вече не ще мога да си обръсна брадата, която израстна докато го изобретя ;)

[линк]

salle.online.bg/sig