| Summary: | ASTERISK-16288: Memory leak on reload | ||
| Reporter: | Jeremy B (captainjez) | Labels: | |
| Date Opened: | 2010-06-24 20:20:24 | Date Closed: | 2011-06-07 14:00:39 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) memory_output.zip | |
| Description: | I've compiled a fresh version of Asterisk 1.6.2.7 under FreeBSD 8.0, however on a "dialplan reload" or "module reload" the memory usage of Asterisk jumps on average by around 100k in size. When I reduce the hash_users, hash_peers and hash_dialogs sizes down from the defaults, the memory jump is reduced to around 10-15k on average. I've set them to: hash_users=150 hash_peers=50 hash_dialogs=50 I'm able to always reproduce this, i've tried removing modules to see if there's something specific causing a leak, however to no avail. Details are as follows: FreeBSD 8.0-RELEASE-p3 #0: Wed May 26 05:45:12 UTC 2010 root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC Asterisk was compiled from source, the version in ports tree is too far behind so we can't use this. Happy to provide any other information required to assist. Thanks. | ||
| Comments: | By: Jeremy B (captainjez) 2010-06-26 18:43:31 I've just built Asterisk 1.6.2.9 and i'm still having the issue. I'm not running DAHDi, and i've got the following modules loaded: app_cdr.so app_chanisavail.so app_channelredirect.so app_confbridge.so app_db.so app_dial.so app_exec.so app_forkcdr.so app_macro.so app_originate.so app_parkandannounce.so app_playback.so app_queue.so app_read.so app_readexten.so app_record.so app_senddtmf.so app_sendtext.so app_setcallerid.so app_sms.so app_softhangup.so app_system.so app_transfer.so app_verbose.so app_voicemail.so bridge_builtin_features.so bridge_multiplexed.so bridge_simple.so bridge_softmix.so cdr_sqlite3_custom.so chan_bridge.so chan_iax2.so chan_local.so chan_sip.so codec_alaw.so codec_ulaw.so format_g729.so format_sln.so format_wav.so format_wav_gsm.so func_callerid.so func_cdr.so func_channel.so func_config.so func_cut.so func_devstate.so func_dialgroup.so func_dialplan.so func_env.so func_extstate.so func_global.so func_groupcount.so func_logic.so func_module.so func_shell.so func_strings.so func_timeout.so func_vmcount.so func_volume.so pbx_config.so pbx_loopback.so res_clioriginate.so res_convert.so res_limit.so res_monitor.so res_musiconhold.so res_timing_pthread.so By: Tilghman Lesher (tilghman) 2010-06-27 22:03:42 Compile with MALLOC_DEBUG and get the output of "memory show summary" and "memory show allocations", then do a "module reload", repeat the first two commands, and upload all of the output as files to this issue. By: Jeremy B (captainjez) 2010-06-27 23:57:01 I've uploaded the information as requested. By: Tilghman Lesher (tilghman) 2010-06-28 11:18:16 I honestly don't see any memory leak in that output. If there's any real memory leak, it's either in one of the 3rd party libraries loaded or it's just normal Linux memory allocation and nothing to be concerned with. By: Tilghman Lesher (tilghman) 2010-06-28 15:26:10 If you can show a slow memory leak that manifests in the information that you've provided, then we can take a look at that, but right now, there isn't anything else that we can see is wrong. By: Jeremy B (captainjez) 2010-06-28 15:53:16 I'll gather some more data for you over the next couple of days. By: Jeremy B (captainjez) 2010-06-28 15:54:05 Also to note this is freebsd not Linux. By: Digium Subversion (svnbot) 2010-07-10 10:11:01 Repository: asterisk Revision: 275469 _U branches/1.6.2/ U branches/1.6.2/channels/chan_sip.c U branches/1.6.2/configs/sip.conf.sample ------------------------------------------------------------------------ r275469 | russell | 2010-07-10 10:11:01 -0500 (Sat, 10 Jul 2010) | 29 lines Merged revisions 245192 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r245192 | mmichelson | 2010-02-06 08:43:03 -0600 (Sat, 06 Feb 2010) | 21 lines Remove useless sip options related to hash table size. First off, these options weren't actually doing anything. By the time the options were parsed, the peer and dialog containers had already been allocated with their default values. Second, hash table size is something that doesn't really make sense to change in a config file. If a user is that interested in changing the hashtable size, he can modify the source itself. I have removed the parsing of the hash_peer, hash_user, and hash_dialog options. I have removed the hash_user_size variable altogether since it is not used at all. I also changed hash_peer_size and hash_dialog_size to be constant, and have changed the symbols to be in all caps as constants typically are. I have also removed the entire section in sip.conf.sample regarding configurable hashtable sizes. ........ (merge to 1.6.2 inspired by issue ASTERISK-16288) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=275469 By: Leif Madsen (lmadsen) 2010-07-21 12:26:53 Also I see res_timing_pthread being in use here -- please test after this revision: http://svn.digium.com/view/asterisk?view=rev&revision=278465 The system should be much more stable with res_timing_pthread. By: Paul Belanger (pabelanger) 2010-08-04 11:56:02 Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information can be found at http://www.asterisk.org/developers/bug-guidelines | ||