Ruby / Glibc coredump (двойное освобождение или повреждение)

Question

Я использую инструмент распределенной непрерывной интеграции, который я написал сам в Ruby. Он использует форк «политики» Майка Перхама для распределения задач. Модуль "policy" использует потоки для части mDNS.

Время от времени я сталкиваюсь с дампом ядра, который я не понимаю:

*** glibc detected *** ruby: double free or corruption (fasttop): 0x086d8600 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7cef494]
/lib/libc.so.6[0xb7cf0b93]
/lib/libc.so.6(cfree+0x6d)[0xb7cf3c7d]
/usr/lib/libruby18.so.1.8[0xb7e8adf8]
/usr/lib/libruby18.so.1.8(ruby_xmalloc+0x85)[0xb7e8b395]
/usr/lib/libruby18.so.1.8[0xb7e5065e]
...
/usr/lib/libruby18.so.1.8[0xb7e717f4]
/usr/lib/libruby18.so.1.8[0xb7e74296]
/usr/lib/libruby18.so.1.8(rb_yield+0x27)[0xb7e7fb57]
======= Memory map: ========
...

Я работаю на Gentoo и перекомпилировал Ruby и Glibc с помощью "-gdbg" и отключил чередование, чтобы получить осмысленное ядро:

...
Core was generated by `ruby /home/develop/dcc/bin/dcc-worker'.
Program terminated with signal 6, Aborted.
#0  0xb7f20410 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7f20410 in __kernel_vsyscall ()
#1  0xb7cacb60 in *__GI___open_catalog (cat_name=0x6 <Address 0x6 out of bounds>, nlspath=0xbf9d6f00 " ", env_var=0x0, catalog=0x1) at open_catalog.c:237
#2  0xb7cae498 in __sigdelset (set=0x6) from /lib/libc.so.6
#3  *__GI_sigfillset (set=0x6) at ../signal/sigfillset.c:42
#4  0xb7ce952d in freopen64 (filename=0x2 <Address 0x2 out of bounds>, mode=0xb7db02c8 "\" total=\"%zu\" count=\"%zu\"/>\n", fp=0x9) at freopen64.c:47
#5  0xb7cef494 in _IO_str_init_readonly (sf=0x86d8600, ptr=0xb7eef5a9 "te\213V\b\205\322\017\204\220", size=-1210273804) at strops.c:88
#6  0xb7cf0b93 in mALLINFo (av=0xb) at malloc.c:5865
#7  0xb7cf3c7d in __libc_calloc (n=141395456, elem_size=3214793136) at malloc.c:4019
#8  0xb7e8adf8 in ?? () at gc.c:1390 from /usr/lib/libruby18.so.1.8
#9  0x086d8600 in ?? ()
#10 0xb7e89400 in rb_gc_disable () at gc.c:256
#11 0xb7e8b395 in add_freelist () at gc.c:1087
#12 gc_sweep () at gc.c:1186
#13 garbage_collect () at gc.c:1524
#14 0xb7e5065e in ?? () from /usr/lib/libruby18.so.1.8
#15 0x00000340 in ?? ()
#16 0x00000000 in ?? ()
(gdb) 

Хм ??? Для меня это выглядит как Рубин-стажер. Что касается других проблем «двойного освобождения или повреждения» здесь, в stackoverflow, я видел, что, возможно, потоки являются частью проблемы.

Также проблема не возникает в точно такой же позиции. У меня есть другая обратная трассировка, которая намного длиннее, но сбой также в garbage_collect, но с немного другим путем:

(gdb) bt
#0  0xffffe430 in __kernel_vsyscall ()
#1  0xf7c8b8c0 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0xf7c8d1f5 in *__GI_abort () at abort.c:88
#3  0xf7cc7e35 in __libc_message (do_abort=2, fmt=0xf7d8daa8 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:170
#4  0xf7ccdd24 in malloc_printerr (action=2, str=0xf7d8dbec "double free or corruption (fasttop)", ptr=0x911f5d0) at malloc.c:6197
#5  0xf7ccf403 in _int_free (av=0xf7daa380, p=0x911f5c8) at malloc.c:4750
#6  0xf7cd24ad in *__GI___libc_free (mem=0x911f5d0) at malloc.c:3716
#7  0xf7e68768 in obj_free () at gc.c:1366
#8  gc_sweep () at gc.c:1174
#9  garbage_collect () at gc.c:1524
#10 0xf7e68be5 in rb_newobj () at gc.c:436
#11 0xf7eb9840 in str_alloc (klass=0) at string.c:67
... (150 lines of rb_eval/call/yield etc.)

Кто-нибудь предлагал, как изолировать и, возможно, решить эту проблему?

Answer 1

Быстро, просто и не так полезно: export MALLOC_CHECK_=2. Это заставляет glibc выполнять дополнительный уровень проверки во время free(), чтобы избежать повреждения кучи. Он будет abort() и даст дамп ядра, как только обнаружит повреждение, вместо того, чтобы ждать, пока возникнет реальная проблема, вызванная повреждением.

Не так быстро и просто, но гораздо полезнее (если вы работаете): valgrind .

Answer 2

Valgrind позволяет легко находить проблемы с повреждением кучи. При использовании Ruby 1.8 под valgrind сообщается о некоторых ложных ошибках, но их можно устранить, используя этот патч ruby ​​ (и настраивая с помощью --enable-valgrind) или используя файл подавления valgrind, Чтобы запустить вашу программу ruby ​​под valgrind, просто добавьте к команде префикс valgrind:

valgrind ruby /home/develop/dcc/bin/dcc-worker

Если процесс сбоя является дочерним по отношению к процессу, который вы запускаете, используйте valgrind --trace-children=yes. В частности, обратите внимание на неверных записей , которые являются признаком повреждения кучи.

Answer 3

Я получил эту же ошибку в простой программе на языке C, называемой rd_test; он просто прочитал бы указанное количество байтов, используя read (2) из ​​заданного входного файла (это может быть файл устройства).

Ошибка фактическая оказалась переполнением буфера на 1 байт (как я сделал ... ЬиЕ [п] = '\ 0'; ... где 'n' - это количество байтов, считанных в буфер 'buf'). Глупый я.

НО, дело в том, что я никогда не ловил это, пока не запустил его с Вальгриндом! Так что IMHO valgrind определенно стоит того, чтобы работать в подобных случаях.

Ошибка «двойного освобождения или искажения» исчезла, как только я избавился от ошибочной ошибки.

Answer 4

Я получил то же сообщение об ошибке не в ruby, а в zenity-программе. Я обнаружил, что со мной что-то было, закрывая два раза открытую трубу! Проверьте, не освобождаете ли вы два или более раз одну и ту же кучу памяти, закрывая снова закрытые файлы или каналы. Гудлак