core dump at _dl_sysinfo_int80()

Question

Я создал TCP-клиент, который подключается к серверу прослушивания. Мы также сохранили TCP. Несколько раз клиент терпит крах и сбрасывает ядро. Ниже приведены следы отвалов ядра.

Проблема в версии ядра Linux Обновление 4, ядро ​​2.6.9-42.0.10.

у нас было два основных свалки.

(gdb) where 
#0 0x005e77a2 in _dl_sysinfo_int80() from /ddisk/d303/dumps/mhx239131/ld- 
linux.so.2 
#1 0x006c8bd1 in connect() from /ddisk/d303/dumps/mhx239131/libc.so.6 
#2 0x08057863 in connect_to_host() 
#3 0x08052f38 in open_ldap_connection() 
#4 0x0805690a in new_connection() 
#5 0x08052cc9 in ldap_open() 
#6 0x080522cf in checkHosts() 
#7 0x08049b36 in pollLDEs() 
#8 0x0804d1cd in doOnChange() 
#9 0x0804a642 in main() 

(gdb) where 
#0 0x005e77a2 in _dl_sysinfo_int80() from /ddisk/d303/dumps/mhx239131/ld- 
linux.so.2 
#1 0x0068ab60 in __nanosleep_nocancel ( 
from /ddisk/d303/dumps/mhx239131/libc.so.6 
#2 0x080520a2 in Sleep() 
#3 0x08049ac1 in pollLDEs() 
#4 0x0804d1cd in doOnChange() 
#5 0x0804a642 in main() 

Мы попытались воспроизвести проблему в нашей среде, но мы не смогли.

Что может вызвать основной файл?

Пожалуйста, помогите мне избежать такой ситуации.

Спасибо, Naga

Answer 1

_dl_sysinfo_int80 это просто функция, которая делает системный вызов в ядро. Таким образом, дамп ядра происходит при системном вызове (возможно, тот, который используется в первом примере connect, и nanosleep во втором примере), вероятно, потому, что вы передаете недопустимые указатели.

Недопустимые указатели могут быть вызваны тем, что код, который вызывает эти функции, сломан или потому, что в другом месте в программе сломан и повреждает память программы.

Посмотрите на два кадра выше (кадр #2) в дампе ядра для обоих примеров и проверьте передаваемые параметры. К сожалению, похоже, что вы не компилировались с отладочной информацией, что затрудняло их просмотр.

Кроме того, я предлагаю попробовать valgrind и посмотреть, найдет ли он что-то.

Answer 2

Ваша программа почти cetainly сделала не coredump в любом из указанных выше мест.

Скорее всего, у вас либо есть несколько потоков в вашем процессе (и какой-то другой поток, вызванный дампом ядра), либо что-то внешнее, вызвавшее процесс вашего процесса (например, 'kill -SIGABRT <pid>').

Если у вас есть несколько потоков, GDB 'info threads' и 'thread apply all where', скорее всего, предоставят дополнительные подсказки.