использование хуков glibc malloc в потокобезопасном режиме

ОБНОВЛЕНО

Вы имеете право не доверять __malloc_hooks; Я взглянул на код, и он - поразительно безумно - не является потокобезопасным.

Вызов унаследованных хуков напрямую, а не восстановление и повторный ввод malloc, кажется, слишком сильно отклоняется от документа, который вы цитируете, чтобы было удобно его предлагать.

Из http://manpages.sgvulcan.com/malloc_hook.3.php:

Переменные-хуки не являются потокобезопасными, поэтому теперь они устарели. Вместо этого программисты должны вытеснять вызовы соответствующих функций, определяя и экспортируя такие функции, как «malloc» и «free».

Подходящий способ внедрения функций debug malloc / realloc / free - это предоставить вашу собственную библиотеку, которая экспортирует ваши «отладочные» версии этих функций, а затем уступает место реальным. Связывание C выполняется в явном порядке, поэтому, если две библиотеки предлагают одну и ту же функцию, используется первая из указанных. Вы также можете внедрить свой malloc во время загрузки в unix, используя механизмы LD_PRELOAD.

http://linux.die.net/man/3/efence описывает электрическое ограждение, который подробно описывает оба этих подхода.

Вы можете использовать свою собственную блокировку, если в этих функциях отладки, если это необходимо.

У меня точно такая же проблема. Я решил это на этом примере. Если мы не определяем THREAD_SAFE, у нас есть пример, приведенный этим человеком, и у нас есть ошибка сегментации. Если мы определим THREAD_SAFE, у нас не будет ошибки сегментации.

#include <malloc.h>
#include <pthread.h>

#define THREAD_SAFE
#undef  THREAD_SAFE

/** rqmalloc_hook_  */

static void* (*malloc_call)(size_t,const void*);

static void* rqmalloc_hook_(size_t taille,const void* appel)
{
void* memoire;

__malloc_hook=malloc_call; 
memoire=malloc(taille);    
#ifndef THREAD_SAFE
malloc_call=__malloc_hook;   
#endif
__malloc_hook=rqmalloc_hook_; 
return memoire;
}

/** rqfree_hook_ */   

static void  (*free_call)(void*,const void*);

static void rqfree_hook_(void* memoire,const void* appel)
{
__free_hook=free_call;   
free(memoire);            
#ifndef THREAD_SAFE
free_call=__free_hook;    
#endif
__free_hook=rqfree_hook_; 
}

/** rqrealloc_hook_ */

static void* (*realloc_call)(void*,size_t,const void*);

static void* rqrealloc_hook_(void* memoire,size_t taille,const void* appel)
{
__realloc_hook=realloc_call;     
memoire=realloc(memoire,taille); 
#ifndef THREAD_SAFE
realloc_call=__realloc_hook;    
#endif
__realloc_hook=rqrealloc_hook_; 
return memoire;
}

/** memory_init */

void memory_init(void)
{
  malloc_call  = __malloc_hook;
  __malloc_hook  = rqmalloc_hook_;

  free_call    = __free_hook;
  __free_hook    = rqfree_hook_;

  realloc_call = __realloc_hook;
  __realloc_hook = rqrealloc_hook_;
 }

 /** f1/f2 */

 void* f1(void* param)
 {
 void* m;
 while (1) {m=malloc(100); free(m);}
 }

 void* f2(void* param)
 {
 void* m;
 while (1) {m=malloc(100); free(m);}
 }

 /** main */
 int main(int argc, char *argv[])
 {
 memory_init();
 pthread_t t1,t2;

 pthread_create(&t1,NULL,f1,NULL);
 pthread_create(&t1,NULL,f2,NULL);
 sleep(60);
 return(0);
 }

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

[РЕДАКТИРОВАТЬ] IANAL, но ... Если вы можете использовать glibc в своем коде, вы можете посмотреть на код (поскольку это LGPL, любой, кто его использует, должен иметь разрешение есть копия источника). Поэтому я не уверен, что вы правильно поняли правовую ситуацию или, возможно, вам не разрешено использовать glibc в вашей компании по закону.

[EDIT2] Поразмыслив, я понял, что эта часть пути вызова должна быть защищена какой-то блокировкой, которую glibc создает для вас. В противном случае использование хуков в многопоточном коде никогда не будет работать надежно, и я уверен, что в документации это упоминается. Поскольку malloc() должен быть потокобезопасным, перехватчики тоже должны быть.

Если вы все еще беспокоитесь, я предлагаю написать небольшую тестовую программу с двумя потоками, которые выделяют и освобождают память в цикле. Увеличьте счетчик на крючке. После миллиона раундов счетчик должен быть ровно два миллиона. Если это так, то ловушка также защищена блокировкой malloc().

[EDIT3] Если тест не прошел, значит, из-за вашей правовой ситуации невозможно реализовать монитор. Расскажите своему боссу, и пусть он сам примет решение.

[EDIT4] Googling обнаружил этот комментарий из отчета об ошибке:

Крючки не являются поточно-ориентированными. Период. Что ты пытаешься исправить?

Это часть обсуждения в марте 2009 г. ошибки в libc/malloc/malloc.c, которая содержит исправление. Так что, возможно, версия glibc после этой даты работает, но, похоже, нет гарантии. Это также, похоже, зависит от вашей версии GCC.

Невозможно использовать обработчики malloc поточно-ориентированным способом при рекурсии в malloc. Интерфейс плохо спроектирован, вероятно, не подлежит ремонту.

Даже если вы поместите мьютекс в свой код ловушки, проблема в том, что вызовы malloc не видят эти блокировки до тех пор, пока они не пройдут через механизм ловушки, и, чтобы пройти через механизм ловушки, они смотрят на глобальные переменные (указатели ловушек ) без получения вашего мьютекса. Когда вы сохраняете, изменяете и восстанавливаете эти указатели в одном потоке, они влияют на вызовы распределителя в другом потоке.

Основная проблема дизайна заключается в том, что хуки по умолчанию являются нулевыми указателями. Если бы интерфейс просто предоставлял ненулевые хуки по умолчанию, которые являются собственно распределителем (распределитель нижнего уровня, который больше не вызывает никаких хуков), тогда было бы просто и безопасно добавлять хуки: вы могли бы просто сохранить предыдущие хуки, а в новых перехватчиках рекурсивно переходите в malloc, вызывая перехватчики удержания, без возни с какими-либо глобальными указателями (кроме времени установки перехватчика, что может быть выполнено до запуска любых потоков).

В качестве альтернативы, glibc может предоставить внутренний интерфейс malloc, который не вызывает перехватчиков.

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

В его нынешнем виде, что вы можете сделать для безопасного использования ловушки glibc malloc, так это избежать повторного обращения к malloc. Не изменяйте указатели ловушек внутри обратных вызовов ловушек, а просто вызывайте свой собственный распределитель.