[asterisk-bugs] [JIRA] (ASTERISK-21050) Asterisk 1.8.19.1 crashes on startup

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-21050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=202745#comment-202745 ] 

Matt Jordan commented on ASTERISK-21050:
----------------------------------------

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.
                
> Asterisk 1.8.19.1 crashes on startup
> ------------------------------------
>
>                 Key: ASTERISK-21050
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21050
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Configuration
>    Affects Versions: 1.8.19.0
>         Environment: $ uname -rsm
> NetBSD 6.0 i386
>            Reporter: Emmanuel Dreyfus
>            Severity: Critical
>
> Asterisk always crahses on startup after upgrading from version 1.8.10.1 to  1.8.19.1.
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira