]> git.ipfire.org Git - thirdparty/asterisk.git/commit
loader: Retry dlopen when loading fails 74/2074/7
authorGeorge Joseph <george.joseph@fairview5.com>
Sat, 23 Jan 2016 21:50:57 +0000 (14:50 -0700)
committerGeorge Joseph <george.joseph@fairview5.com>
Thu, 3 Mar 2016 21:38:01 +0000 (15:38 -0600)
commit195100e770e3a6f5252be85187539149df7c6781
tree5a6ff1504ba3d11bda5884a2b83e4b51d2768e0e
parent6705f308cb075dd1319924a1fc70590e69a14fca
loader: Retry dlopen when loading fails

Although we use the RTLD_LAZY flag when calling dlopen
the first time on a module, this only defers resolution
for function calls.  Pointer references to functions are
determined at link time so dlopen expects them to be there.
Since we don't cross-module link, pointers to functions
in other modules won't be available and dlopen will fail.

Doing a "hardened" build also causes problems because it
typically sets "-z now" on the ld command line which
overrides RTLD_LAZY at run time.

If the failing module isn't a GLOBAL_SYMBOLS module, then
dlopen will be called again after all the GLOBAL_SYMBOLS
modules have been loaded and they'll eventually resolve.

If the calling module IS a GLOBAL_SYMBOLS module itself
and a third module depends on it, then there's an issue
because the second time through the dlopen loop,
GLOBAL_SYMBOLS modules aren't given any special treatment
and since the order in which dlopen is called isn't
deterministic, the dependent may again be tried before the
module it needs is loaded.

Simple solution:  Save modules that fail load_resource
because of a dlopen error in a list and retry them
immediately after the first pass. Keep retrying until
the failed list is empty or we reach a #defined max
retries. Error messages are suppressed until the final
pass which also gets rid of those confusing error messages
about module failures that are later corrected.

Change-Id: Iddae1d97cd2f00b94e61662447432765755f64bb
main/loader.c