Пользовательский менеджер памяти с локальным хранилищем потоков
В нашей программе есть собственный менеджер памяти, все наши вызовы malloc / free управляются менеджером памяти, но в начале программы getpwuid () будет вызываться, и на компьютере некоторых клиентов с активированным nss_ldap он будет вызывать malloc из libc, а не из нашего менеджера памяти, что приводит к ошибке в нашем менеджере памяти, стековый отчет из gdb:
Breakpoint 2, 0x0000003df8cc6eb0 in brk () from /lib64/libc.so.6
0 0x0000003df8cc6eb0 in brk () from /lib64/libc.so.6
1 0x0000003df8cc6f72 in sbrk () from /lib64/libc.so.6
2 0x0000003df8c73d29 in __default_morecore () from /lib64/libc.so.6
3 0x0000003df8c70090 in _int_malloc () from /lib64/libc.so.6
4 0x0000003df8c70c9d in malloc () from /lib64/libc.so.6
5 0x0000003df880fc65 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2
6 0x00002aaaae302a7c in _nss_ldap_inc_depth () from /lib64/libnss_ldap.so.2
7 0x00002aaaae2f91a4 in _nss_ldap_enter () from /lib64/libnss_ldap.so.2
8 0x00002aaaae2f942c in _nss_ldap_getbyname () from /lib64/libnss_ldap.so.2
9 0x00002aaaae2f9aa9 in _nss_ldap_getpwuid_r () from /lib64/libnss_ldap.so.2
10 0x0000003df8c947c5 in getpwuid_r@@GLIBC_2.2.5 () from /lib64/libc.so.6
11 0x0000003df8c9412f in getpwuid () from /lib64/libc.so.6
12 0x0000000001414be3 in lc_username ()
Я проследил код _nss_ldap_inc_depth (), кажется, вызов __tls_get_addr () вызван тем, что используется локальное хранилище потока, я пытаюсь изменить диспетчер памяти на разделяемую библиотеку, но __tls_get_addr () по-прежнему вызывает malloc из libc Как я могу заставить его вызвать наш менеджер памяти вместо libc?
Решение
Ты можешь использовать LD_PRELOAD загрузить вашу библиотеку перед любой другой библиотекой (включая glibc), и вместо этого она будет связана, что-то вроде:
$ LD_PRELOAD=/path/to/library/libmymalloc.so /bin/myprog
Там учебник Вот это показывает, как это работает, даже пример malloc
Другие решения
Вы можете изменить свой менеджер памяти для использования mmap инстред brk,
Там может быть только один пользователь brk в процессе. Так что, если вы не заменили все звонки на malloc и связанные функции (calloc, strdup и более), вы не должны использовать brk,
mmapОднако таких проблем нет. Ваш менеджер памяти может использовать mmap, а также malloc все еще может работать параллельно.
detector