Menu
What are some of the reasons dlopen could segfault besides the shared object not existing?
In my case, I know the shared object exists, but when my program goes to load it using dlopen, it segfaults. I checked in my lib folder and the shared object is there and the paths are all correct.
handle = dlopen(libraryName.c_str(), RTLD_LAZY | RTLD_GLOBAL);
gdb bt:
#0 0x00000000001b94f5 in ?? ()
#1 0x00007fffefd96db6 in __do_global_ctors_aux () from /usr/local/lib/MY_LIB2.so
#2 0x00007fffefcf82c3 in _init () from /usr/local/lib/MY_LIB2.so
#3 0x00007fffed69c6c8 in ?? () from /usr/local/lib/MY_LIB1.so
#4 0x00007ffff7de9dc4 in call_init () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7de9ef6 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#6 0x00007ffff7dedf43 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#7 0x00007ffff7de9c36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#8 0x00007ffff7ded7ca in _dl_open () from /lib64/ld-linux-x86-64.so.2
#9 0x00007ffff5c5af26 in dlopen_doit () from /lib64/libdl.so.2
#10 0x00007ffff7de9c36 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#11 0x00007ffff5c5b4cf in _dlerror_run () from /lib64/libdl.so.2
#12 0x00007ffff5c5afc1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2
#13 0x00007ffff6ecef7e in mynamespace::Factory::attachModule (this=0x61d440, libraryName=...) at Factory.cpp:324
#14 0x00007ffff6ecefe6 in mynamespace::Factory::attachFunction (this=0x61d440, functionName=..., moduleName=...) at Factory.cpp:343
#15 0x00007ffff6ecdd16 in mynamespace::Factory::ReadFile (this=0x61d440, x=...) at Factory.cpp:111
#16 0x00007ffff6ecda62 in mynamespace::Factory::ReadDirectory (this=0x61d440, x=...) at Factory.cpp:79
#17 0x00007ffff6ecdc66 in mynamespace::Factory::ReadDirectory (this=0x61d440, x=0x417901 "/usr/local/lib/") at Factory.cpp:105
#18 0x0000000000410637 in main (argc=2, argv=0x7fffffffdd58) at main.cpp:78
719
Overview. A segmentation fault (aka segfault) is a common condition that causes programs to crash; they are often associated with a file named core . Segfaults are caused by a program trying to read or write an illegal memory location.
A segmentation fault occurs when a program attempts to access a memory location that it is not allowed to access, or attempts to access a memory location in a way that is not allowed (for example, attempting to write to a read-only location, or to overwrite part of the operating system).
They are both called exceptions, but they originate at different levels of the software/hardware of the system. Technically, you can catch segfaults with a signal handler for SIGSEGV . However, as Ivaylo explains, it's is not, typically, allowed to just "try again" if you get a segfault.
You can't catch segfaults. Segfaults lead to undefined behavior - period (err, actually segfaults are the result of operations also leading to undefined behavior.
In addition to loading a library into memory and fixing up references, the runtime linker runs initializers such as functions labelled __attribute__((constructor)), an init function (if specified with -Wl,-init,...), and constructors for global objects. Your backtrace indicates that one of those is failing.
Specifically, __do_global_ctors_aux runs constructors for global objects. Check those.
176
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
