[asterisk-bugs] [JIRA] (ASTERISK-26074) res_odbc: Deadlock within UnixODBC

Kevin Harwell (JIRA) noreply at issues.asterisk.org
Tue May 31 11:32:57 CDT 2016


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

Kevin Harwell commented on ASTERISK-26074:
------------------------------------------

Do you have a threading level specified in your unixodbc configuration for your driver? If so make sure it is set to 0. Doing so passes threading control to the underlying driver. From the unixodbc DriverManager/__handles.c code:
{noformat}
/*                                                                                                                                                                                   
 * use just one mutex for all the lists, this avoids any issues                                                                                                                      
 * with deadlocks, the performance issue should be minimal, if it                                                                                                                    
 * turns out to be a problem, we can readdress this                                                                                                                                  
 *                                                                                                                                                                                   
 * We also have a mutex to protect the connection pooling code                                                                                                                       
 *                                                                                                                                                                                   
 * If compiled with thread support the DM allows four different                                                                                                                      
 * thread strategies:                                                                                                                                                                
 *                                                                                                                                                                                   
 * Level 0 - Only the DM internal structures are protected.                                                                                                                          
 * The driver is assumed to take care of itself                                                                                                                                      
 *                                                                                                                                                                                   
 * Level 1 - The driver is protected down to the statement level.                                                                                                                    
 * Each statement will be protected, and the same for the connect                                                                                                                    
 * level for connect functions. Note that descriptors are considered                                                                                                                 
 * equal to statements when it comes to thread protection.                                                                                                                           
 *                                                                                                                                                                                   
 * Level 2 - The driver is protected at the connection level. Only                                                                                                                   
 * one thread can be in a particular driver at one time.                                                                                                                             
 *                                                                                                                                                                                   
 * Level 3 - The driver is protected at the env level, only one thing                                                                                                                
 * at a time.                                                                                                                                                                        
 *                                                                                                                                                                                   
 * By default the driver opens connections with lock level 0; drivers                                                                                                                
 * are expected to be thread safe now. This can be changed by adding                                                                                                                 
 * the line                                                                                                                                                                          
 *                                                                                                                                                                                   
 * Threading = N                                                                                                                                                                     
 *                                                                                                                                                                                   
 * to the driver entry in odbcinst.ini, where N is the locking level                                                                                                                 
 * (0-3)                                                                                                                                                                             
 *                                                                                                                                                                                   
 */
{noformat}

> res_odbc: Deadlock within UnixODBC
> ----------------------------------
>
>                 Key: ASTERISK-26074
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26074
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_odbc
>    Affects Versions: SVN, 13.9.1
>         Environment: CentOS 7 / Fedora Server 23
>            Reporter: Ross Beer
>         Attachments: backtrace-threads-clean.txt, core-show-locks.txt
>
>
> The appears to be a lock in the sorcery real-time identify module in the latest versions of asterisk. I have tried multiple versions of unixODBC and mysql-connector-odbc with out any luck.
> The locks cause all registrations to fail.
> The CLI is showing a couple of message types:
> [2016-05-30 16:49:43] WARNING[25214]: pjproject:0 <?>:  sip_transactio Unable to register REGISTER transaction (key exists)
> [2016-05-30 16:49:43] WARNING[25477]: pjproject:0 <?>:  sip_transactio Unable to register REGISTER transaction (key exists)
> [2016-05-30 16:49:43] WARNING[25479]: pjproject:0 <?>:  sip_transactio Unable to register REGISTER transaction (key exists)
> [2016-05-30 16:49:29] ERROR[25207]: res_pjsip.c:2899 ast_sip_create_dialog_uas: Could not create dialog with endpoint 20937*407. Object already exists (PJ_EEXISTS)



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



More information about the asterisk-bugs mailing list