|Summary:||ASTERISK-15719: glibc 2.11.1 causes asterisk to not start due to return code from dlclose|
|Reporter:||Quentin Armitage (pqa)||Labels:|
|Date Opened:||2010-03-01 10:10:16.000-0600||Date Closed:||2014-03-05 09:55:21.000-0600|
|Description:||On Fedora-12, with its current glibc (glibc-2.11.1-1), asterisk fails to start up when it loads any module.|
In main/loader.c there are 4 instances of the following code:
dlclose() in glibc-2.11.1-1 returns 0 (SUCCESS) even if the library has already been closed, and consequently the while loop never terminates.
On Fedora-11 (with glibc-2.10.2-1) and Fedora-13 (with glibc-2-11-90.14), dlclose() returns -1 if the library is already closed, and so the problem does not occur.
This issue certain occurs with asterisk version 126.96.36.199 and later (including current SVN head).
****** ADDITIONAL INFORMATION ******
I reported this as a bug in glibc (see https://bugzilla.redhat.com/show_bug.cgi?id=569060 ), and the response was that this is undefined behaviour.
I have reported the problem against Asterisk in Fedora, (see https://bugzilla.redhat.com/show_bug.cgi?id=569384 ), and have been asked to report it upstream. There is an ugly patch attached to that bug report as a workaround to the problem.
|Comments:||By: Leif Madsen (lmadsen) 2010-03-03 09:47:25.000-0600|
Ya, I'm not 100% sure what we'll do here. If it works fine in an older and a newer version of glibc, I'd suppose I'd recommend avoiding that version :)
By: Quentin Armitage (pqa) 2010-03-03 10:08:51.000-0600
The concern must be that if the behaviour of dlclose() is undefined if the library is already closed, then the behaviour of the while (dlclose(lib)); loop is undefined, and may break again in the future.
Is it possible to get a definitive answer on the behaviour of dlclose() in this circumstance, since if it is undefined, then Asterisk is relying on undefined behaviour, which could cause problems for both new ports, and for future upgrades.
By: Leif Madsen (lmadsen) 2010-03-03 13:22:20.000-0600
After discussion, this is definitely something we'll need to deal with as Asterisk is relying on undefined behaviour.
By: Rusty Newton (rnewton) 2013-04-04 14:07:55.693-0500
Appears to be duplicated by ASTERISK-21050 which has an attached patch.
By: Matt Jordan (mjordan) 2014-03-05 09:55:21.595-0600
This was fixed in r402287 in 1.8+.