LINUX.ORG.RU

демон, утечка памяти, краш


0

0

Написал демона на Си, который постоянно находится в памяти и что-то делает.

Есть две проблемы:
1) Немного поджирает память, за сутки схедает примерно 10Мб оперативки, как вычислить, где что не остается?
2) Раз в несколько дней падает, отладчик gdb после анализа дампа говорит:
Program terminated with signal 8, Arithmetic exception.
#0 0x0000000000405734 in ?? ()

Какие есть способы вычислить точнее хотя бы примерный участок кода, где это произошло?

Ответ на: комментарий от LamerOk

>> постоянно находится в памяти и что-то делает.

Ящитаю, это вин.


Смеялся всем шредером :)

power ()
Ответ на: комментарий от dreamer

>собрать с отладочной инфой и смотреть gdb

Ну я собирал с опцией -g, но отладчик ничего нового не показал (я им смотрел core-файл)
Или под отладчиком нужно запускать демона и гонять? Я себе это не представляю, ведь программа может нормально работать несколько суток, мне что сидеть и крутить ее вручную? :) Я просто раньше не пользовался отладчиком, не поясните?

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

> сидеть и крутить ее вручную?

Да, разумеется.

LamerOk ★★★★★ ()

Арефметическое исключение на процессоре? или еще что нить?

скорее всего проблемы с FPU

namezys ★★★★ ()

Сделай чтоль логирование действий, хотя бы узнаешь, после чего он выпадает.

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

Ну там команды bt, list и т.д. должны показать, в каком месте кода программа падает. Командой print можно посмотреть содержимое переменных в этот момент. Ну и т.д. Можно смотреть core файл, можно запускать демон из отладчика (и необязательно при этом сидеть рядом).

tim239 ()

Сбилдь с -g -ggdb.
После анализируйте крэш.
Если не покажет конструктива (знаки вопроса в кол стэке) - значит съехал стэк.
Про память Ваv правильно сказали valgrind.

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

>> постоянно находится в памяти и что-то делает.

Ящитаю, это вин.


+1 :)

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

Пардон, не заметил, что у автора прога падает. Вопрос отменяется.

runtime ★★★ ()

1) man 3 mtrace
2) ну у вас же написан адрес инструкции (регистр RIP, если это x86_64). Стека нет, ну и ладно. objdump -j .text -D 'программа' и ищете там этот адрес. Если objdump не показывает имена функций, значит бинарный файл стрипованный, перекомпилировать (лучше с отладкой, -g).

anonymous ()
Ответ на: комментарий от metallic

>Я просто раньше не пользовался отладчиком, не поясните?

ТруЪ! :)

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

>Арефметическое исключение на процессоре? или еще что нить?

скорее всего проблемы с FPU

Сказано же, «что-то делает». На ноль делит, например)

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

> ну у вас же написан адрес инструкции (регистр RIP, если это x86_64). Стека нет, ну и ладно. objdump -j .text -D 'программа' и ищете там этот адрес. Если objdump не показывает имена функций, значит бинарный файл стрипованный, перекомпилировать (лучше с отладкой, -g).

Программа скомпилена с -g, архитекрута да - x86_64. Сделал objdump -j .text -D 'программа' - вывалило кучу всего интересного и не понятного :)

Делаем:
# objdump -j .text -D 'программа' | grep 0000000000405734
ничего не показало

# objdump -j .text -D 'программа' | grep 405734
405734: 48 f7 75 d8 divq 0xffffffffffffffd8(%rbp)

Это оно? Эта строчка находится в секции 0000000000405020 <main>:

metallic ()

С помощью valgrind нашел несколько незначительных утечек и устранил, но основные остались, вроде как он даже показывает где, но я не пойму почему, связано это с mysql. Вот например:

==33566== 367,200 bytes in 45 blocks are possibly lost in loss record 32 of 34
==33566== at 0x24667B: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==33566== by 0xD22901: my_malloc (in /usr/local/lib/mysql/libmysqlclient.so.16)
==33566== by 0xD2591D: alloc_root (in /usr/local/lib/mysql/libmysqlclient.so.16)
==33566== by 0xD3B6D9: unpack_fields (in /usr/local/lib/mysql/libmysqlclient.so.16)
==33566== by 0xD3C646: cli_read_query_result (in /usr/local/lib/mysql/libmysqlclient.so.16)
==33566== by 0xD3AC6D: mysql_real_query (in /usr/local/lib/mysql/libmysqlclient.so.16)
==33566== by 0x40295F: exec_query (vpnms_functions.c:174)
==33566== by 0x402A59: username_by_ip (vpnms_functions.c:209)
==33566== by 0x404A13: vpnmsd_nf_thread (vpnmsd_nf_thread.c:166)
==33566== by 0xF994D0: ??? (in /lib/libthr.so.3)

Вот ф-ия exec_query:

MYSQL_RES *exec_query(char *query)
{
   MYSQL_RES   *res;
   MYSQL       mysql;

   if ( 0 == strcasecmp (vpnms_config.vpnms_sql_debug, «yes») )
      syslog (LOG_DEBUG, «SQL: %s», query);

   mysql_init(&mysql);
   if (!mysql_real_connect(&mysql, vpnms_config.mysql_host, vpnms_config.mysql_username, vpnms_config.mysql_password,
         vpnms_config.mysql_database, vpnms_config.mysql_port, NULL, 0))
   {
      syslog (LOG_ERR, «Failed to connect to database: Error: %s\n», mysql_error(&mysql));
      exit(EXIT_FAILURE);
   }

if ( mysql_real_query(&mysql, query, strlen(query)) )
{
      syslog (LOG_ERR, «Query failed: Error: %s\n», mysql_error(&mysql));
      exit(EXIT_FAILURE);
   }
free(query);

res = mysql_store_result(&mysql);

mysql_close(&mysql);

return res;
}

Вроде бы все очищается, где что остается?

metallic ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.