Summary:ASTERISK-21050: Asterisk crash during startup - issues with dlclose() return code checks and module loading registration
Reporter:Emmanuel Dreyfus (manu0208)Labels:
Date Opened:2013-02-08 04:06:23.000-0600Date Closed:2014-03-05 09:55:00.000-0600
Versions: Frequency of
duplicatesASTERISK-15719 glibc 2.11.1 causes asterisk to not start due to return code from dlclose
is related toASTERISK-22538 Apparent loop in dlclose while loading dynamic modules during Asterisk startup
Environment:$ uname -rsm NetBSD 6.0 i386Attachments:( 0) patch-main_loader.c
Description:Asterisk always crahses on startup after upgrading from version to

I have been able to restore its functionality through the patch here: \[edit - patch link removed by mjordan\]

There are two issues:

1- Fix incorrect dlclose() return code checks. This was reported in issue ASTERISK-15719 but is not yet fixed as far as I understand. The current code will call dlclose() more than once after it was successful, leading to undefined behavior because the passed handle is not valid anymore. My patch fixes the return value checks.

2- For some reason I have not yet fully understood, the module loader may attempt to load a module twice. On second attempt, module is not registered a second time. The current code checks for registration by looking if the module was the last added. On the second load attempt, the current code fails to find the module as the last one in the list, considers that registration failed, and unloads the module. This causes crashes because the module is still registered as loaded from the first attempt, and its now unmapped memory regions are still referenced. My patch fixes registration check by walking the whole module list instead of checking last item.
Comments:By: Matt Jordan (mjordan) 2013-02-08 09:03:51.183-0600

First, we cannot consider patches that are not attached to the issue after signing a license contributor agreement. As such, I've removed the link to the patch.

Second, the code does load a module twice. A multi-pass approach on the modules is done to ensure that modules that export global symbols or use the optional API linkage are loaded before modules that depend on those symbols. Ensuring that this occurs must happen for Asterisk to load modules correctly - when you've signed a license contributor agreement, the patch can be reviewed to determine whether or not it affects this behavior.

By: Rusty Newton (rnewton) 2013-03-01 15:28:25.141-0600

Please sign the contributor agreement and submit your patch through the proper process. https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-DigiumSubmissionLicenseAgreement

By: Matt Jordan (mjordan) 2013-03-15 22:07:07.839-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines

By: Emmanuel Dreyfus (manu0208) 2013-03-16 08:21:56.794-0500

This issue is not resolved, it should not be closed. There is no activity because my developer agreement was not validated, an issue which is not in my hands since I sent it a long time ago to your legal department. I do not know how to unlock that frustrating situation.

By: Rusty Newton (rnewton) 2013-04-02 13:49:21.151-0500

Even if you don't have a contributors agreement signed you can still post to let us know what is going on.

If you uploaded the patch before you had the contributors agreement signed then it will not show up.

I see now that you have a valid agreement - re-upload the patch and (More Actions > Attach Files) and be sure to mark it as a contribution. I'll ping a core developer to take a look at it then.

By: Emmanuel Dreyfus (manu0208) 2013-04-02 19:39:28.407-0500

upload again my patch from 2013-02-08

By: Rusty Newton (rnewton) 2013-04-03 14:26:41.169-0500

Thanks. Can you provide instructions for a user to reproduce the crash? That'll make it easier for others to test the patch.

By: Emmanuel Dreyfus (manu0208) 2013-04-03 20:47:44.327-0500

At mine it just crash on startup. I suspect it is because I do not autoload all modules. Here is my modules.conf:
load => func_callerid.so
load => app_dial.so
load => codec_ulaw.so
load => chan_sip.so
load => res_realtime.so
load => res_config_ldap.so
load => res_rtp_asterisk.so
load => pbx_config.so
load => app_cdr.so
load => cdr_csv.so
load => func_cdr.so
load => format_wav.so
load => res_musiconhold.so
load => bridge_builtin_features.so
load => app_transfer.so
load => app_macro.so
load => app_voicemail.so
load => format_gsm.so
load => format_wav_gsm.so

By: Rusty Newton (rnewton) 2013-04-04 14:06:25.541-0500

This looks like it duplicates ASTERISK-15719.

What version of glibc are you currently using?

I'll leave this open and link the issues since you have a patch on this that works for you and may be useful to whoever finally works the other issue.

By: Matt Jordan (mjordan) 2014-03-05 09:54:51.405-0600

This ended up getting fixed independently in r402287 in Asterisk 1.8+. Unfortunately, when it was fixed, I didn't see your patch - a very similar approach was taken, although it was slightly different in the implementation.

Since this is no longer a problem in Asterisk 1.8+, I'm going to go ahead and close this out as fixed.