summaryrefslogtreecommitdiff
path: root/main/loader.c
diff options
context:
space:
mode:
authorMatthew Jordan <mjordan@digium.com>2013-10-31 16:06:14 +0000
committerMatthew Jordan <mjordan@digium.com>2013-10-31 16:06:14 +0000
commite9fc32105353a65b89f546008ca98ffadf359704 (patch)
tree70a65a5e14d8b96f8d4ced65abcb08e2b7b1d7e2 /main/loader.c
parent981983bfdef664e5b275ff097173198784218f78 (diff)
core/loader: Don't call dlclose in a while loop
For awhile now, we've noticed continuous integration builds hanging on CentOS 6 64-bit build agents. After resolving a number of problems with symbols, strange locks, and other shenanigans, the problem has persisted. In all cases, gdb shows the Asterisk process stuck in loader.c on one of the infinite while loops that calls dlclose repeatedly until success. The documentation of dlclose states that it returns 0 on success; any other value on error. It does not state that repeatedly calling it will eventually clear those errors. Most likely, the repeated calls to dlclose was to force a close by exhausting the references on the library; however, that will never succeed if: (a) There is some fundamental error at work in the loaded library that precludes unloading it (b) Some other loaded module is referencing a symbol in the currently loaded module This results in Asterisk sitting forever. Since we have matching pairs of dlopen/dlclose, this patch opts to only call dlclose once, and log out as an ERROR if dlclose fails to return success. If nothing else, this might help to determine why on the CentOS 6 64-bit build agent things are not closing successfully. Review: https://reviewboard.asterisk.org/r/2970 ........ Merged revisions 402287 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 402288 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 402289 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Diffstat (limited to 'main/loader.c')
-rw-r--r--main/loader.c22
1 files changed, 13 insertions, 9 deletions
diff --git a/main/loader.c b/main/loader.c
index 4065043aa..8c581838f 100644
--- a/main/loader.c
+++ b/main/loader.c
@@ -412,9 +412,18 @@ static struct ast_module *find_resource(const char *resource, int do_lock)
*/
static void logged_dlclose(const char *name, void *lib)
{
- if (dlclose(lib) != 0) {
- ast_log(LOG_WARNING, "Failed to unload %s: %s\n",
- name, dlerror());
+ char *error;
+
+ if (!lib) {
+ return;
+ }
+
+ /* Clear any existing error */
+ dlerror();
+ if (dlclose(lib)) {
+ error = dlerror();
+ ast_log(AST_LOG_ERROR, "Failure in dlclose for module '%s': %s\n",
+ S_OR(name, "unknown"), S_OR(error, "Unknown error"));
}
}
@@ -457,12 +466,7 @@ static void unload_dynamic_module(struct ast_module *mod)
/* WARNING: the structure pointed to by mod is going to
disappear when this operation succeeds, so we can't
dereference it */
-
- if (!lib) {
- return;
- }
-
- logged_dlclose(name, lib);
+ logged_dlclose(ast_module_name(mod), lib);
/* There are several situations where the module might still be resident
* in memory.