When shared object which contains the symbols which cannot be resolved is tried to be loaded twice by using dlopen with RTLD_NOW option, first dlopen call fail (this is correct action), but second dlopen call succeed (this is illegal action). Perhaps, when dlopen fail to resolve symbols, dlopen doesn't release mmap and module handle, does it? Fix: correct dlopen function. How-To-Repeat: input follow files: =========================== foo.c: #include <stdio.h> #include <stdlib.h> #include <dlfcn.h> int main() { void *h; if (NULL == (h=dlopen("var.so", RTLD_NOW))) { puts(dlerror()); } else printf("success : %p\n", dlsym(h, "_var")); if (NULL == (h=dlopen("var.so", RTLD_NOW))) { puts(dlerror()); } else printf("success : %p\n", dlsym(h, "_var")); return 0; } ============================== and var.c: extern void hoge(void); void var(void) { hoge(); /* undefined symbol */ } =============== And, compile and execute as follow: % gcc -o foo foo.c % gcc -c -fPIC var.c % ld -Bshareable -o var.so var.o % ./foo Undefined symbol "_hoge" in foo:var.so success : 0x2001b020 %
Responsible Changed From-To: freebsd-bugs->jdp I'll take a look at this.
State Changed From-To: open->closed This PR applies to the a.out dynamic linker, which is essentially obsolete at this point. The ELF dynamic linker does not exhibit the bug.