<p>Richard Mudgett <strong>posted comments</strong> on this change.</p><p><a href="https://gerrit.asterisk.org/8288">View Change</a></p><p>Patch set 1:</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">Instead of doing this as a pjproject patch, can we do it in<br>res_pjsip/load_pjsip instead?  Maybe use their pool_dbg?</p></blockquote></blockquote></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Unfortunately, pool_dbg and the caching_pool are currently mutually<br>exclusive compile time selections.  You can have one or the other.<br>You cannot select these pools at run time.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;">><br>> If this can be accomplished at runtime I think that would be<br>> better.  This would allow use of an option like cache_media_frames<br>> to disable pool caching for use with valgrind (without needing<br>> MALLOC_DEBUG).</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">Yes.  That would be nice.</p><blockquote style="border-left: 1px solid #aaa; margin: 10px 0; padding: 0 10px;"><p style="white-space: pre-wrap; word-wrap: break-word;"><br>Another option might be to simply clone the cached pool factory as<br>a non-cached version and submit it upstream.  Then add a<br>pjsip.conf/system option to use the cached or non-cached memory<br>pool factory.</p></blockquote><p style="white-space: pre-wrap; word-wrap: break-word;">I suppose I could create a non-cached pool factory patch for bundled.<br>Creating that pool isn't that bad.  The complexity comes in detecting<br>the pool's availability and selecting it when requested.</p><p style="white-space: pre-wrap; word-wrap: break-word;">We shouldn't send it upstream because this is to allow MALLOC_DEBUG<br>or valgrind visibility into the bundled pjproject's memory usage.  An<br>external pjproject adds unnecessary detection complexity when they<br>can already build pjproject and asterisk with the dbg_pool for use<br>with valgrind.  Though, there might be some compiler warnings about<br>some cache related unused variables in asterisk.</p><ul style="list-style: none; padding-left: 20px;"></ul><p>To view, visit <a href="https://gerrit.asterisk.org/8288">change 8288</a>. To unsubscribe, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/8288"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: master </div>
<div style="display:none"> Gerrit-MessageType: comment </div>
<div style="display:none"> Gerrit-Change-Id: I64d5befbaeed2532f93aa027a51eb52347d2b828 </div>
<div style="display:none"> Gerrit-Change-Number: 8288 </div>
<div style="display:none"> Gerrit-PatchSet: 1 </div>
<div style="display:none"> Gerrit-Owner: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Corey Farrell <git@cfware.com> </div>
<div style="display:none"> Gerrit-Reviewer: George Joseph <gjoseph@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Jenkins2 </div>
<div style="display:none"> Gerrit-Reviewer: Joshua Colp <jcolp@digium.com> </div>
<div style="display:none"> Gerrit-Reviewer: Richard Mudgett <rmudgett@digium.com> </div>
<div style="display:none"> Gerrit-Comment-Date: Sat, 24 Feb 2018 01:33:00 +0000 </div>
<div style="display:none"> Gerrit-HasComments: No </div>