Created attachment 397073 [details] Ugly patch to work around dlclose issue Description of problem: Asterisk fails to complete startup when loading modules, and loops forever. Version-Release number of selected component (if applicable): At least asterisk-1.6.1.12-1.fc12.i686 and later versions (build from source RPMs) How reproducible: Always Steps to Reproduce: 1./etc/init.d/asterisk start 2. 3. Actual results: asterisk loops Expected results: asterisk starts up successfully Additional info: In main/loader.c, there are 4 instances of: while (!dlclose(lib)); In glibc version 2.11.1-1 (current in F-12), dlclose returns 0 (success) even if the library has already been closed. This results in the loop continuing indefinitely. With glibc-2.10.2-1 (current in F-11) dlclose returns an error if the libary is already closed, and so the loop terminates. I reported this as a bug against glibc - see bug #569060 - but have received the response that it is undefined behaviour. Attached is a fairly horrible patch that is a workaround that allows asterisk to successfully start up.
Has this been reported upstream to Digium?
I have now tested this in F-13, with glibc-2.11.90-14, and asterisk successfully starts up. This appears to be an issue only with F-12/glibc-2.11.1-1
No, I haven't reported it upstream. Would you like me to do so?
Yes, please report it upstream and put a link to the upstream bug report so that I can track it.
Report upstream at https://issues.asterisk.org/view.php?id=16934
Since I don't really understand dynamic libraries and dlopening/dlclosing I'm going to defer this to upstream and see what they say about it.
Upstream has now reported: After discussion, this is definitely something we'll need to deal with as Asterisk is relying on undefined behaviour. Is there some patch that could be applied in Fedora in the meantime that will allow Asterisk to load?
Is this 100% repeatable for everyone? I haven't been using 1.6.1.x on F-12, all of my installs are on CentOS or rawhide/F-13. I'm not sure why Asterisk needs to try and close dlopened modules more than once, is it to prevent some sort of memory leak? Are there common failure conditions that dlclose will actually fail to close a module?
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This problem needs to be fixed upstream since Asterisk is relying on undefined behaviour (upstream bug has been reported but not resolved yet). However, it appears that the behaviour of dlclose in glibc has changed between F12 and F13 so the problem is no longer exhibited in F13.
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.