This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
problem w/plugin libraries and incorrect memory addresses
- From: Mantra Wind River Thrum <mwgthrum at gmail dot com>
- To: binutils at sourceware dot org
- Date: Wed, 21 Jan 2009 21:51:54 -0600
- Subject: problem w/plugin libraries and incorrect memory addresses
Dear binutils experts,
I'd be forever grateful for the solution to the following problem:
I have a program which links to many libraries (Qt, lapack, atlas, and
many more) and also loads plugin libraries via dlopen().
The plugin consists of only these functions:
void controller()
{
cout << "got here" << endl;
}
void init(Object* x)
{
void (**fn)() = &x->fn;
*fn = controller;
// these two statements equivalent to x->fn = controller and are
used to illustrate the problem
}
The program that loads the plugin (highly simplified and modified for
brevity):
int main()
{
Object o;
typedef void (*init_t)();
// load init function
void* handle = dlopen("plugin.so", DTLD_NOW);
assert(handle);
init_t init = (init_t) dlsym(handle, "init");
const char *dlsym_error = dlerror();
assert(!dlsym_error);
(*init)(&o);
// run controller
if (o.controller)
(*o.controller)();
else
cout << "no controller!" << endl;
}
Running this program yields the output "no controller!"
Debugging with gdb reveals that the statement void (**fn) = &x->fn
uses the wrong memory address for x->fn (it is off by 0x70 bytes
according to gdb): the program is writing to the wrong location (I've
verified this by examining the memory at that location).
I wouldn't mind including the source for my program, but it depends on
many libraries, at least one of which I can guarantee you don't have
installed.
Some clues:
If I link the code together with the program that loads and executes
the plugin (i.e., making it no longer a plugin), the code works
fine.
valgrind does not indicate any problems
I've tried RTLD_NOW, RTLD_GLOBAL, and RTLD_LAZY- makes no difference
In the past, I had weird problems occurring within my plugins (C++
RTTI would fail inexplicably when using data passed to the plugin),
but I was able to get around these problems and didn't spend the time
to diagnose the situation.
Source files are compiled with -fPIC
Problem occurs on 3 different unix machines (2 machines running
different distributions of linux and an OS X leopard machine).
I've tried building all third party libraries as shared libraries to
no effect.
Problem disappears if I remove one of the libraries (Coin 3D library),
but I'm unsure whether this is actually due to the problem actually
going away or some other effect.
Thanks for your help and your time,
Mantra