[asterisk-bugs] [JIRA] (ASTERISK-24287) Race conditons and other problems in res_config_pgsql

[Sean Bright (JIRA)]

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

Sean Bright closed ASTERISK-24287.
----------------------------------

                  Resolution: Fixed
    Target Release Version/s: 14.4.0
                              13.15.0

Etienne,

I believe that all of the issues that you enumerated were resolved by [this commit|https://gerrit.asterisk.org/#/c/5076]. It will be in the next release of Asterisk 13 and 14.

> Race conditons and other problems in res_config_pgsql
> -----------------------------------------------------
>
>                 Key: ASTERISK-24287
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24287
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_config_pgsql
>    Affects Versions: 11.12.0
>            Reporter: Etienne Lessard
>      Target Release: 13.15.0, 14.4.0
>
>
> While looking to fix a deadlock in res_config_pgsql, I found that there was quite a few problems with the module. Here's what I found:
> In the find_table function, if database is NULL and the table is not found in the cache, than the lock on the psql_tables list is not released. An easy way to produce such a deadlock is to call the command "realtime show psql cache foobar" from the CLI; if your database doesn't have a table named "foobar", then the next thread which will try to acquire the psql_tables lock will deadlock.
> The find_table function sometimes calls the pgsql_exec function, but it doesn't lock the pgsql_lock mutex before, and the find_table function is not always called with the pgsql_lock mutex locked.  This can cause a range of undefined behaviour if other threads are executing in res_config_pgsql, ranging from crash to deadlock. I've personally observed both.
> The command "realtime show pgsql status" use the pgsql connection without obtaining the lock first.
> The ESCAPE_STRING macro reference the pgsql connection, but once again, the lock is not systematically acquired before the macro is used, so this can lead to undefined behaviour.
> I also found other, less critical problems.
> I know the res_config_psql module is an "extended support" module. I would have liked to provide a patch to fix the numerous problems, but didn't have the time, and I instead made the switch to res_config_odbc. That said, I've still decided to open this bug, to let other people know that there's quite a few issues with the module.



--
This message was sent by Atlassian JIRA
(v6.2#6252)