Re: [Crash-utility] [PATCH] extension: Fix crash segfaults when loading same extension with different names twice

Hello Kazu, RTLD_DEEPBIND is not a good way. I'd like to recall the patch. After my research, I find making functions and global variables static within extensions can avoid such problems. Taking extensions/trace.so as example, trace_fini and trace_init are non-static functions, if we load trace.so first, everything works fine, but when we rename trace.so to trace2.so and load it again, we are expecting trace_init within trace2.so to be called, but since we have RTLD_GLOBAL, actually it's the trace_init within trace.so to be called. It causes problems because currently some global variables within trace.so are not in their initial status. As I quoting dlopen manual: Symbol references in the shared object are resolved using (in order): symbols in the link map of objects loaded for the main program and its dependencies; symbols in shared objects (and their dependencies) that were previously opened with dlopen() using the RTLD_GLOBAL flag; and definitions in the shared object itself (and any dependencies that were loaded for that object). When using readelf --dyn-syms trace.so, for non-static trace_fini and trace_init, I got: Symbol table '.dynsym' contains 66 entries: .... 64: 0000000000007e65 22 FUNC GLOBAL DEFAULT 11 trace_fini 65: 0000000000007e3d 40 FUNC GLOBAL DEFAULT 11 trace_init Since I'm not an expert to linkers and loaders, I guess the process is: 1. when loading trace.so 2. ld.so sees trace_init and trace_fini in .dynsym 3. ld.so searches the 2 symbols in main program, RTLD_GLOBAL shared objects, and trace.so. 4. ld.so finds them in trace.so, resolves their address. 5. everything works fine. 6. when loading trace2.so 7. ld.so sees trace_init and trace_fini in .dynsym 8. ld.so searches the 2 symbols in main program, RTLD_GLOBAL shared objects, and trace2.so. 9. ld.so finds them in RTLD_GLOBAL shared objects(trace.so), resolves their address. 10. trace_init in trace.so is called again, but global variables are not in initial status, fails. If I make trace_fini and trace_init static, readelf --dyn-syms trace.so will no longer give the 2 symbols in .dynsym, and ld.so will no longer resolve them to the wrong place, then it works fine. I think this cannot be a code patch, but a document for future extension developers, if you don't want to export a symbol to subsequent extensions, making it static. On Mon, Mar 22, 2021 at 1:35 PM HAGIO KAZUHITO(萩尾 一仁) <k-hagio-ab(a)nec.com&gt; wrote: