Summary:	ASTERISK-19920: res_adsi module is loaded (or Asterisk thinks it is) despite no modules.conf, noload or autoload=no instructions
Reporter:	Leif Madsen (lmadsen)	Labels:
Date Opened:	2012-05-29 07:51:48	Date Closed:	2012-06-13 14:01:20
Priority:	Minor	Regression?	Yes
Status:	Closed/Complete	Components:	Core/Configuration Resources/res_adsi
Versions:	11	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:
Description:	While updating the installation chapter in Asterisk: The Definitive Guide, I was testing everything, and one part of the book has us building all the configuration files from scratch. While starting that, we have the user load Asterisk with just asterisk.conf and indications.conf (no modules.conf or other files). We then have the user run 'module show' to demonstrate that no modules are loaded. However, sometime between Asterisk 1.8 and 11 (trunk), the res_adsi module seems to be auto-loaded by default, even with no modules.conf, which was not expected. If this is intentional that is fine, I'd like to document why that is. If it is not intentional, then I suppose it should be fixed :)
Comments:	By: Leif Madsen (lmadsen) 2012-05-29 07:52:11.262-0500 Note I put this as a bug, although I suppose it could have been filed as an information request. By: Leif Madsen (lmadsen) 2012-05-29 07:58:09.873-0500 Also of note, I used, in modules.conf (after creating it with autoload=yes), a {noformat}noload => res_adsi.so{noformat} I was surprised to see it in the list still of 'module list'. I then tried to: {noformat}module unload res_adsi.so{noformat} And received: {noformat}Unload failed, 'res_adsi.so' is not loaded. Unable to unload resource res_adsi.so Command 'module unload res_adsi.so' failed.{noformat} By: Mark Michelson (mmichelson) 2012-06-06 15:21:44.775-0500 This does not happen to me in trunk revision 368637. By: Mark Michelson (mmichelson) 2012-06-06 16:06:26.955-0500 I've ssh'd into Leif's machine that exhibits the problem. I've tried the following things on my own machine and still have not reproduced: * Run as non-root * Run without an asterisk.conf or indications.conf The only thing that we can point to that may be different is that Leif is using a fresh installation of Ubuntu 12.04 and I'm using a well-seasoned installation of Ubuntu 10.04. I don't know how that could be affecting things, but it's currently the only thing that we can think of as a difference. By: Mark Michelson (mmichelson) 2012-06-12 16:20:22.490-0500 I have now reproduced it and will give some further information on the problem. I reproduced this on an Ubuntu 12.04 virtual machine. The big difference that I am seeing between this machine and the one where the issue does not occur is that on the problematic machine, ast_module_register() is being called prior to main(). On the working version, ast_module_register() is called for the first time when the main() function calls load_modules(). I also have determined that this problem actually has nothing to do with res_adsi. After reproducing the issue, I then recompiled Asterisk and unchecked res_adsi in menuselect. "module show" now shows a "core" module loaded. Right now, my guess for why this is happening is due to compiler version. I'm planning to do research on whether the "constructor" attribute has changed in recent veresions of gcc, because that seems to be the origin of the call to ast_module_register() in the broken scenario. By: Mark Michelson (mmichelson) 2012-06-12 16:55:18.650-0500 I added in a call to ast_backtrace() in ast_module_register() and this is the backtrace that is printed, whether res_adsi is compiled or not: #0 main/loader.c:148 ast_module_register() #1 res/res_adsi.c:1155 __reg_module() #2 buildinfo.c:0 __libc_csu_init() I do not trust this backtrace. By: Mark Michelson (mmichelson) 2012-06-12 17:04:34.161-0500 On my VM, I downgraded to gcc 4.4.7 (from 4.6.3) and the problem no longer occurs. I've zeroed in on the cause but not the explanation. By: Mark Michelson (mmichelson) 2012-06-13 08:55:05.761-0500 I did a downgrade to gcc 4.5.3 and the problem happens with that version as well. By: Mark Michelson (mmichelson) 2012-06-13 11:34:26.792-0500 As another comment, I tried to see if this is a problem if a modules.conf file is provided and a module is loaded. To be specific, I created a modules.conf file that had only a load=>app_echo line in it. With this, the problem still persists. Asterisk claims to have two modules loaded, app_echo, and core. So apparently, there will be an extra module claimed to be loaded by Asterisk beyond what actually is loaded. Trying to figure out why this is happening is proving difficult.