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-0600 | Date Closed: | 2005-01-12 21:05:34.000-0600 |
Priority: | Critical | Regression? | No |
Status: | Closed/Complete | Components: | 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 |