From: Matthew Jordan <mjordan@digium.com>
Date: Thu, 31 Oct 2013 15:59:50 +0000 (+0000)
Subject: core/loader: Don't call dlclose in a while loop
X-Git-Tag: 11.8.0-rc1~49
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=45a6969b3c5320965c20360036af01a1bc6253d8;p=thirdparty%2Fasterisk.git

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


git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@402288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
---

diff --git a/main/loader.c b/main/loader.c
index a0bec43eb4..314d7dd0b0 100644
--- a/main/loader.c
+++ b/main/loader.c
@@ -377,6 +377,24 @@ static struct ast_module *find_resource(const char *resource, int do_lock)
 }
 
 #ifdef LOADABLE_MODULES
+
+static void close_lib(const char *name, void *lib)
+{
+	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"));
+	}
+}
+
 static void unload_dynamic_module(struct ast_module *mod)
 {
 	void *lib = mod->lib;
@@ -384,9 +402,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)
-		while (!dlclose(lib));
+	close_lib(ast_module_name(mod), lib);
 }
 
 static enum ast_module_load_result load_resource(const char *resource_name, unsigned int global_symbols_only, struct ast_heap *resource_heap, int required);
@@ -435,7 +451,7 @@ static struct ast_module *load_dynamic_module(const char *resource_in, unsigned
 	if (resource_being_loaded != (mod = AST_LIST_LAST(&module_list))) {
 		ast_log(LOG_WARNING, "Module '%s' did not register itself during load\n", resource_in);
 		/* no, it did not, so close it and return */
-		while (!dlclose(lib));
+		close_lib(resource_in, lib);
 		/* note that the module's destructor will call ast_module_unregister(),
 		   which will free the structure we allocated in resource_being_loaded */
 		return NULL;
@@ -446,7 +462,7 @@ static struct ast_module *load_dynamic_module(const char *resource_in, unsigned
 	/* if we are being asked only to load modules that provide global symbols,
 	   and this one does not, then close it and return */
 	if (global_symbols_only && !wants_global) {
-		while (!dlclose(lib));
+		close_lib(resource_in, lib);
 		return NULL;
 	}
 
@@ -471,7 +487,7 @@ static struct ast_module *load_dynamic_module(const char *resource_in, unsigned
 	}
 #endif
 
-	while (!dlclose(lib));
+	close_lib(resource_in, lib);
 	resource_being_loaded = NULL;
 
 	/* start the load process again */