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

Rusty Newton (JIRA) noreply at issues.asterisk.org
Wed Apr 3 14:24:01 CDT 2013


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

Rusty Newton updated ASTERISK-21050:
------------------------------------

    Assignee: Rusty Newton  (was: Emmanuel Dreyfus)
      Status: Reopened  (was: Waiting for Feedback)
    
> 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
>            Assignee: Rusty Newton
>            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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list