[asterisk-bugs] [JIRA] (ASTERISK-21050) Asterisk crash during startup - issues with dlclose() return code checks and module loading registration

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan closed ASTERISK-21050.
----------------------------------

    Resolution: Fixed

> Asterisk crash during startup - issues with dlclose() return code checks and module loading registration
> --------------------------------------------------------------------------------------------------------
>
>                 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
>         Attachments: patch-main_loader.c
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)