LINUX.ORG.RU
Форум — Development  

valgrind + MySQL++


0

0 

Это вообще жесть.
Я начинаю задумываться о своей профпригодности:

#include "mysql++.h"
int main()
{

	mysqlpp::Connection *connection= new mysqlpp::Connection();
	delete connection;		

	return 0;
}

valgrind:
==15851== 16 bytes in 1 blocks are still reachable in loss record 1 of 1
==15851==    at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==15851==    by 0x437C05C: my_malloc (in /usr/lib/libmysqlclient.so.15.0.0)
==15851==    by 0x437CDAA: my_error_register (in /usr/lib/libmysqlclient.so.15.0.0)
==15851==    by 0x437BC8F: init_client_errs (in /usr/lib/libmysqlclient.so.15.0.0)
==15851==    by 0x437A948: mysql_server_init (in /usr/lib/libmysqlclient.so.15.0.0)
==15851==    by 0x43A1F69: mysql_init (in /usr/lib/libmysqlclient.so.15.0.0)
==15851==    by 0x4146662: mysqlpp::DBDriver::DBDriver() (dbdriver.cpp:48)
==15851==    by 0x4141D46: mysqlpp::Connection::Connection(bool) (connection.cpp:41)
==15851==    by 0x804C4A4: main (sql.cpp:5)
==15851== 
==15851== LEAK SUMMARY:
==15851==    definitely lost: 0 bytes in 0 blocks.
==15851==      possibly lost: 0 bytes in 0 blocks.
==15851==    still reachable: 16 bytes in 1 blocks.
==15851==         suppressed: 0 bytes in 0 blocks.
★★☆
← Есть ли у debian lenny -xml парсер?
java-1.6 + jdbc + ? →

в чем жесть-то ? ... ну память где-то в libmysqlclient.so выделилась и не освободилась, чего такого-то ?

а мож valgrind адо как-нить настроить ...

anonymous
()

>Я начинаю задумываться о своей профпригодности

Если уже так говорить, то стоит задуматься о профпригодности авторов libmysqlclient (или, возможно, mysql++). Вы использовали библиотеку корректно, не выходя за рамки интерфейсов, потому утечки памяти (которые по стеку вызовов происходят _не в Вашем коде_) -- не Ваша проблема.

Хотя разработчиков mysql тоже можно понять -- проект огромный, и устранить _все_ утечки не представляется возможным. Если хотите помочь проекту -- разберитесь, почему возникает утечка; напишите патч, устраняющий проблему и пришлите его разработчикам -- думаю, они будут Вам благодарны.

Sectoid ★★★★★
()
Ответ на: комментарий от Sectoid 

Порылся в их багтрекере и нашёл очень много об этом упоминаний.
Разработчики утверждают, что это не баг, а фича.
Дело в том, что либа для ускорения работы минимизирует вызовы
alloc\free...

Для любителей получать 
All heap blocks were freed -- no leaks are possible.
от valgrind`а, создали ф-цию 	mysql_library_end();

Проверил -- всё ок.

Правда в документации об этой ф-ции я упоминания не нашел.

Так что -- пользуйтесь...
Скажем "нет" реальным или мнимым утечкам!

Stahl ★★☆
() автор топика
Ответ на: комментарий от Stahl

>Для любителей получать "All heap blocks were freed -- no leaks are possible." от valgrind`а, создали ф-цию mysql_library_end();

Тогда, возможно, имеет смысл засунуть её вызов в деструктор какого-то внутреннего синглтона в MySQL++. И волки сыты, и овцы целы.

Sectoid ★★★★★
()
Ответ на: комментарий от Sectoid

Это ненужные операции, которые только замедляют завершение программы. Я бы поставил #ifdef-ами для отладочного режима.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

>Это ненужные операции, которые только замедляют завершение программы. Я бы поставил #ifdef-ами для отладочного режима.

Тоже вариант. Или вообще раздельная компиляция.

Sectoid ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Есть ли у debian lenny -xml парсер?
Development
java-1.6 + jdbc + ? →