| Summary: | ASTERISK-03891: memory leak in app_dial option for musiconhold ? | ||
| Reporter: | zoa (zoa) | Labels: | |
| Date Opened: | 2005-04-08 02:57:10 | Date Closed: | 2011-06-07 14:05:19 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Applications/app_dial |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | We are doing a lot of dials iax2 to iax2 with the option 'm'. Looks like approx 50kb of memory is leaked on each call. We tried valgrind, but i locks up everytime we hangup the call. I dont know if the problem also exists when doing just plain musiconhold. But the difference between dial without m or with the m is very obvious. | ||
| Comments: | By: Paul Cadach (pcadach) 2005-04-08 04:42:50 Just for notice: queued calls with MOH also leaks memory. By: Mark Spencer (markster) 2005-04-10 22:26:44 Are you using mpg123 or are you using native moh? By: Mark Spencer (markster) 2005-04-10 22:26:55 (and does it matter which you use) By: Mark Spencer (markster) 2005-04-10 22:27:21 (finally, also try turning on asterisk memory debugging and see if it lets you know anything) By: zoa (zoa) 2005-04-11 02:38:42 will do. We did it with mpg123, as the native moh is only for cvs-head and looks not too easy to backport. I cant try cvs-head due to the big iax2 to iax2 delays in combination with the iaxclient. (the memory leak is only obvious after a lot of calls). By: zoa (zoa) 2005-04-15 06:20:27 we looked at the code for 2 days, couldnt find anything. Then we replaced the mpg123 with an application sending 00000 to the socket and we saw no memory leak. We give up on looking for this bug.... Maybe someone else has the courage to keep going ? By: Paul Cadach (pcadach) 2005-04-15 06:48:16 Is your test application generates zero-stream continuously? mpg123 will stop when its played out all files. So, probably, this could be memory leak due to invalid handling of mpg123 termination? By: Kevin P. Fleming (kpfleming) 2005-04-29 13:03:21 What do we need to do here? Is this still an issue? By: Clod Patry (junky) 2005-05-10 00:00:46 zoa: you tested it only on stable? We need faster feedbacks, if possible. By: Michael Jerris (mikej) 2005-05-26 00:15:59 Last call on this bug. Does astmm help you with this at all? By: zoa (zoa) 2005-05-26 11:34:33 sorry for the late reaction! (Didnt check mantis in a very long time). I gave up with trying, we looked at all the sources, couldnt find a problem, we just stopped using moh. I only tested this on stable indeed. If no one else has issues with this, feel free to close it out. By: Clod Patry (junky) 2005-05-26 11:38:47 close as requested by reporter. If you have time to invest more and find something, feel free to re-open that bug. Thanks. By: Digium Subversion (svnbot) 2008-01-15 15:33:55.000-0600 Repository: asterisk Revision: 5621 U trunk/channels/chan_zap.c ------------------------------------------------------------------------ r5621 | mattf | 2008-01-15 15:33:55 -0600 (Tue, 15 Jan 2008) | 2 lines chan_zap.c portion of PRI show debug command (Bug ASTERISK-3891) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=5621 | ||