[Home]

Summary:ASTERISK-03258: asterisk opens a socket for each incoming MESSAGE and crashes when the limit (eg 500) is reached
Reporter:klaus3000 (klaus3000)Labels:
Date Opened:2005-01-12 03:37:14.000-0600Date Closed:2005-01-12 21:05:34.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-crashtest.pl
( 1) mydiff.txt
( 2) patch_chan_sip.c_1.0.3
Description:I send MESSAGEs to asterisk for keep-alive testing. After 480 MESSAGES asterisk crashes (if I send them one adter another, asterisk crashes completly. If I send them once a minute, asterisk does not crash, but hangs).

The console says:
*CLI> app_qcall:Cannot open queue directory: Too many open files
libgcc_s.so.1 must be installed for pthread_cancel to work

lsof (and netstat) shows that asterisk opens a socket for each incoming MESSAGE. This is weird - there is no media socket needed for MESSAGE.

asterisk  22675     root  790u  IPv4      57864                  UDP mediaserver2.at43.at:10864
asterisk  22675     root  791u  IPv4      57865                  UDP *:10865
asterisk  22675     root  792u  IPv4      57887                  UDP mediaserver2.at43.at:11770
asterisk  22675     root  793u  IPv4      57888                  UDP *:11771
asterisk  22675     root  794u  IPv4      57897                  UDP mediaserver2.at43.at:11636
asterisk  22675     root  795u  IPv4      57898                  UDP *:11637

Btw: to me, this looks like asterisk binds to the IP address  specified in sip.conf for RTP, but binds to all interfaces for RTCP. (= second bug?)


****** ADDITIONAL INFORMATION ******

You can use sipsak and the attached perl script to generate the MESSAGEs. Edit the perl script to fit your IP-addresses.
Comments:By: klaus3000 (klaus3000) 2005-01-12 07:49:13.000-0600

My colleague found the problem - somehow a MESSAGE creates a call which is never deleted. By adding sip_scheddestroy(p, 15000); to the block that handles the MESSAGES this could be solved:

around line 7419 in chan_sip.c
       } else if (!strcasecmp(cmd, "MESSAGE")) {
               if (!ignore) {
                       if (debug)
                               ast_verbose("Receiving message!\n");
                       receive_message(p, req);
               }
               transmit_response(p, "200 OK", req);
------->        sip_scheddestroy(p, 15000); /* axelm */
       } ....

Nevertheless, this is no perfect solution, as there should be no ports opened for incoming MESSAGEs.

I've also made a "diff -u" against stable-1.0.3 chan_sip.
By: Mark Spencer (markster) 2005-01-12 09:21:19.000-0600

Try this patch.  I've gone ahead and committed to CVS head.  This should cause a MESSAGE which is not within the context of a call to disconnect the transaction.
By: Russell Bryant (russell) 2005-01-12 21:05:34.000-0600

I added the fix to stable, too