与我之前的问题有关
我已经成功地插入了malloc
,但calloc
似乎更有问题。
对于某些主机,calloc
陷入无限循环,dlsym
内部可能存在内部calloc
调用。但是,基本测试主机不会表现出此行为,但我系统的"ls"命令会表现出这种行为。
这是我的代码:
// build with: g++ -O2 -Wall -fPIC -ldl -o libnano.so -shared Main.cc
#include <stdio.h>
#include <dlfcn.h>
bool gNanoUp = false;// global
// Function types
typedef void* (*MallocFn)(size_t size);
typedef void* (*CallocFn)(size_t elements, size_t size);
struct MemoryFunctions {
MallocFn mMalloc;
CallocFn mCalloc;
};
MemoryFunctions orgMemFuncs;
// Save original methods.
void __attribute__((constructor)) __nano_init(void) {
fprintf(stderr, "NANO: init()n");
// Get address of original functions
orgMemFuncs.mMalloc = (MallocFn)dlsym(RTLD_NEXT, "malloc");
orgMemFuncs.mCalloc = (CallocFn)dlsym(RTLD_NEXT, "calloc");
fprintf(stderr, "NANO: malloc() found @%pn", orgMemFuncs.mMalloc);
fprintf(stderr, "NANO: calloc() found @%pn", orgMemFuncs.mCalloc);
gNanoUp = true;
}
// replacement functions
extern "C" {
void *malloc(size_t size) {
if (!gNanoUp) __nano_init();
return orgMemFuncs.mMalloc(size);
}
void* calloc(size_t elements, size_t size) {
if (!gNanoUp) __nano_init();
return orgMemFuncs.mCalloc(elements, size);
}
}
现在,当我执行以下操作时,我得到一个无限循环,后跟一个 seg 错误,例如:
% setenv LD_PRELOAD "./libnano.so"
% ls
...
NANO: init()
NANO: init()
NANO: init()
Segmentation fault (core dumped)
但是,如果我注释掉calloc
中介层,它似乎几乎可以工作:
% setenv LD_PRELOAD "./libnano.so"
% ls
NANO: init()
NANO: malloc() found @0x3b36274dc0
NANO: calloc() found @0x3b362749e0
NANO: init()
NANO: malloc() found @0x3b36274dc0
NANO: calloc() found @0x3b362749e0
<directory contents>
...
所以有些东西与"ls"有关,这意味着init()
被调用两次。
编辑请注意,以下主机程序工作正常 - init()
只调用一次,calloc
已成功插入,从输出中可以看出。
// build with: g++ test.cc -o test
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char* argv[]) {
void* p = malloc(123);
printf("HOST p=%pn", p);
free(p);
char* c = new char;
printf("HOST c=%pn", c);
delete c;
void* ca = calloc(10,10);
printf("HOST ca=%pn", ca);
free(ca);
}
% setenv LD_PRELOAD "./libnano.so"
% ./test
NANO: init()
NANO: malloc() found @0x3b36274dc0
NANO: calloc() found @0x3b362749e0
HOST p=0x601010
HOST c=0x601010
HOST ca=0x601030
我有点晚了(6年(。但是我今天想覆盖calloc()
并遇到了一个问题,因为dlsym()
内部使用calloc()
。我使用简单的技术解决了它,并想到在这里分享它:
static unsigned char buffer[8192];
void *calloc(size_t nmemb, size_t size)
{
if (calloc_ptr == NULL) // obtained from dlsym
return buffer;
init(); // uses dlsym() to find address of the real calloc()
return calloc_ptr(len);
}
void free(void *in)
{
if (in == buffer)
return;
free_ptr(in);
}
buffer
满足dlsym()
的需求,直到找到真正的calloc()
并初始化我的calloc_ptr
函数指针。
关于__nano_init()
被调用两次:您已将该函数声明为构造函数,因此在加载库时调用它,并在首次调用malloc()
和calloc()
实现时显式调用第二次。选一个。
关于calloc()
中介层使应用程序崩溃:您正在使用的某些函数(包括dlsym()
和fprintf()
(本身可能正在尝试分配内存,调用中介层函数。考虑后果,并采取相应的行动。
使用基于dlsym
的挂钩可能会导致崩溃,因为dlsym
回调内存分配器。而是使用 malloc 钩子,正如我在你之前的问题中所建议的那样;这些可以在不实际调用dlsym
的情况下安装。
你可以逃脱一个简单地返回 NULL 的初步糟糕的 calloc。这实际上适用于Linux,YMMV。
static void* poor_calloc(size_t nmemb, size_t size)
{
// So dlsym uses calloc internally, which will lead to infinite recursion, since our calloc calls dlsym.
// Apparently dlsym can cope with slightly wrong calloc, see for further explanation:
// http://blog.bigpixel.ro/2010/09/interposing-calloc-on-linux
return NULL; // This is a poor implementation of calloc!
}
你也可以使用 sbrk 为"poor calloc"分配内存。