On 07/30/2015 05:16 PM, Niels de Vos wrote: > On Thu, Jul 30, 2015 at 08:27:15PM +0530, Soumya Koduri wrote: >> Hi, >> >> With the applications using and loading different libraries, the function >> symbols with the same name may get resolved incorrectly depending on the >> order in which those libraries get dynamically loaded. >> >> Recently we have seen an issue with 'snapview-client' xlator lookup fop - >> 'svc_lookup' which matched with one of the routines provided by libntirpc, >> used by NFS-Ganesha. More details are in [1], [2]. > > Indeed, the problem seems to be caused in an execution flow like this: > > 1. nfs-ganesha main binary starts > 2. the dynamic linker loads libntirpc (and others) > 3. the dynamic linker retrieves symbols from the libntirpc (and others) > 4. 'svc_lookup' is amoung the symbols added to a lookup table (or such) > 5. during execution, ganesha loads plugins with dlopen() > 6. the fsalgluster.so plugin is linked against libgfapi and gfapi gets > loaded > 7. libgfapi retrieves the .vol file and loads the xlators, including > snapview-client > 8. snapview-client provices a 'svc_lookup' symbol, same name as > libntirpc provides, complete different functionality So far so good. But I would have expected the compiler to have populated the function pointers in snapview-client's fops table at compile time; the dynamic loader should not have been needed to resolve snapview-client's svc_lookup, because it was (should have been) already resolved at compile time. And in fact it is, but, there are semantics for global (.globl) symbols and run-time linkage that are biting us. -- Kaleb _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
