[asterisk-bugs] [Asterisk 0011694]: Asterisk crashes when connecting the 10th simultaneous ODBC pooled connections

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11694 
====================================================================== 
Reported By:                falves11
Assigned To:                Corydon76
====================================================================== 
Project:                    Asterisk
Issue ID:                   11694
Category:                   Resources/res_odbc
Reproducibility:            always
Severity:                   crash
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 96645 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-06-2008 09:44 CST
Last Modified:              01-08-2008 11:24 CST
====================================================================== 
Summary:                    Asterisk crashes when connecting the 10th
simultaneous ODBC pooled connections
Description: 
After so much work now I nailed the ODBC problem.
I traced how many open connection I have in my SQL server from Asterisk
every second, and inf act, I see 1,2,3,4,5,6,7,8,9,0, and Asterisk crashes.
The capture below is obtained by setting verbose level to 1, and it can be
seen clearly that at the 10th ODBC connection Asterisk is unable to
connect. Yet, the command odbc show gives this output, which proves that
theoretically there is a 1000 limit on the connections.

 Name:   global
  DSN:    mssql
  Pooled: Yes
  Limit:  1000
  Connections in use: 1
    - Connection 1: connected

====================================================================== 

---------------------------------------------------------------------- 
 falves11 - 01-08-08 11:24  
---------------------------------------------------------------------- 
Conclusions from this case:
in /main/util.c we need to double the AST_MAX_LOCKS to 64
in /main/autoservice.c  we need to change MAX_AUTOMONS to 1500

With the new Driver version 10.43 from Easysoft, I can not take it down.
However, Nick Gorgham submitted some very important information to the
ast_development thread, gathered using valgrind. Here is the copy.

"My reading of whats going on is that the scheduler can call

    static int retrans_pkt(const void *data)

And this can run as far as the

    /* Lock channel PVT */
    sip_pvt_lock(pkt->owner);

Then it sits there waiting for the lock to be released. The lock I suspect
was put on this in

    static void __sip_ack(struct sip_pvt *p, int seqno, int resp, int
sipmethod)

which runs its course, and eventually calls

    UNLINK(cur, p->packets, prev);
    dialog_unref(cur->owner);
    ast_free(cur);
    break;

The ast_free releases the memory, but its still referenced by the pkt in
the thread in retransmit_pkt. Then it wakes up the locked thread by caling

    sip_pvt_unlock(p);

But now when the call in retransmit_pkt continues, the memory its using
has actually been free'd by now, so it leads open the chance of corrupting
the heap with the expected entertaining problems."

I hope that from this case we may get a much better Asteris, one that can
rival and beat any commercial soft switch out there. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-08-08 11:24  falves11       Note Added: 0076498                          
======================================================================