Hi, I have been porting NetBSD source in the Linux environment with our own pthread library. system environment: Compiler: arm-linux-gcc-4.3.3 OS: Linux Kernel: 2.6.29 Yes, it never even calls dlerr() in dlcose but NetBSD __dlclose(void *handle) source sequence, int dlclose(void *handle) { Obj_Entry *root = _rtld_dlcheck(handle); if (root == NULL) return -1; _rtld_debug.r_state = RT_DELETE; _rtld_debug_state(); --root->dl_refcount; _rtld_unload_object(root, true); _rtld_debug.r_state = RT_CONSISTENT; _rtld_debug_state(); return 0; } static Obj_Entry * _rtld_dlcheck(void *handle) { Obj_Entry *obj; for (obj = _rtld_objlist; obj != NULL; obj = obj->next) if (obj == (Obj_Entry *) handle) break; xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); if (obj == NULL || obj->dl_refcount == 0) { xwarnx("Invalid shared object handle %p", handle); return NULL; } return obj; } I have printed xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); obj->dl_refcount is getting zero(0). So due to "obj->dl_refcount == 0" the error "invalid shared object handle" is showing. i do not know why this error is coming even though all the constructor/destructor sequences are completed. is it rtld_exit->fini->static C++ destructor->dlcose sequence problem? Thanks & Regards, Venkappa On Wed, Jun 17, 2009 at 5:37 AM, Alexander Kabaev<kabaev_at_gmail.com> wrote: > Hi, > > I do not think we on FreeBSD support NetBSD rtld with our pthread > libraries, unless you already implemented all the necessary glue. > The interface between threading library and rtld is rather intimate and > tricky to get right. > > You provide no code to look at nor explicitly mention what OS and > what version you are running your test on (FreeBSD?), I think you are > on your own. Furthermore, your claim on 'correct' > constructor/destructor is wrong given the sample code provided by > NetBSD PR. > > Some more comments are inline. > > On Tue, 16 Jun 2009 14:59:36 +0530 > venki kaps <venkiece2005_at_gmail.com> wrote: > >> Hi, >> >> I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) >> for ARM/MIPS. >> >> I have C++ static constructor/destructor issue with my rtld. >> >> Problem Report: >> "ld.elf_so does not execute .init/.fini functions in order" and [libc] >> dlclose gives >> "invalid shared object handle" when called through the fini function >> of another module. >> >> The similar NetBSD/freeBSD issues are found from the following >> References: [1] http://gnats.netbsd.org/37347 >> [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=kern/42956 >> >> The above issues are already commited in NetBSD-5-0-RELEASE. >> >> I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided >> static constructor/destructor test and did not find any issues >> with shared pthread combination but noticed [libc] dlclose gives >> "invalid shared object handle" without pthread combination. >> >> The static constructor/destructor test results: >> >> It should be : >> -------------- >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor > > Given the test in Ref[1], both constructor and destructor orders are > wrong above. libdep1 depends on libdep2, so dep2_ctor should be invoked > before dep1_ctor and consequently dep2_dtor should be invoked after > dep1_dtor. > >> While currently I get: >> ---------------------- >> >> with pthreads: >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor >> >> without pthreads: >> >> $ ./foobar >> foo_ctor >> bar_ctor >> tar_ctor >> main_ctor >> dep1_ctor >> dep2_ctor >> dll_ctor >> dll_dtor >> dep2_dtor >> dep1_dtor >> main_dtor >> tar_dtor >> bar_dtor >> foo_dtor >> Invalid shared object handle 0xbdbed400 > > Again, given the sample code from NetBSD PR cannot possibly print this > message because it never even calls dlerr(). You must be looking at > some other code and unless you provide it, understanding your problem > and fixing it is next to impossible. > > Said that, thanks for pointing the FreeBSD PR to me. I will commit the > fix for the problem described here shortly. > >> This gives a "invalid shared object handle" message >> because the refcount field (obj->dl_refcount) for the handle is zero. >> >> I have little bit confused about dlclose destructor >> with/without pthreads. >> >> I have some queries: >> 1) Is it required any changes apart from the >> NetBSD-5-0-RELEASE/{Ref[1],[2]}? 2) Are any changes required in >> thread-stub? >> >> Could anyone provide any inputs to the my issue? >> >> Thanks in advance. >> >> Thanks & Regards, >> Venkappa > > -- > Alexander Kabaev >Received on Thu Jun 18 2009 - 04:08:44 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:50 UTC