<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
I found a hole in the way we handle core variables in FS. Switch_core_get_variable does the lookup and returns the found pointer. In Switch_core_set_variable the first step it does is look up the variable and free it (if it exists). This would free it out from under another that has just done a get on it. This is how I stumbled on this. </blockquote>
<div><br></div><div>The correct place to report bugs is the bug tracker: <a href="http://jira.freeswitch.org/">http://jira.freeswitch.org/</a></div><div><br></div><div>It's a known problem. Basically the answer is you shouldn't really be changing core variables after FS has loaded, at least not while handling traffic. If you're doing so as part of your application, you're doing it wrong. mod_db is probably better suited to what you want to do.</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
Is the right fix is to add a switch_core_get_variable_dup that dups the string while in the mutex protection? I realize in the core case this will require the caller to then free the returned memory, but this is better than getting a bad pointer. This is analogous to the switch_channel_get_variable and it’s _dup implementation, although it dups it to session memory.</blockquote>
<meta charset="utf-8"><div><br></div>Just my 2 cents (I'm not a core developer)... That could be done. But it's also slower because it means dynamically assigning memory and then copying the string. And it can't be cached. And the mutex will make all calls block, not just the single call as with the channel variable - which might possibly introduce a risk of deadlock.<div>
<br><div>-Steve</div><div><br></div><div><br><div><br><div class="gmail_quote">On 2 February 2011 19:39, Kevin Snow <span dir="ltr"><<a href="mailto:kevin.snow@ooma.com">kevin.snow@ooma.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>
<font face="Verdana, Helvetica, Arial"><span style="font-size:12.0px"><br>
I found a hole in the way we handle core variables in FS. Switch_core_get_variable does the lookup and returns the found pointer. In Switch_core_set_variable the first step it does is look up the variable and free it (if it exists). This would free it out from under another that has just done a get on it. This is how I stumbled on this. <br>
<br>
Is the right fix is to add a switch_core_get_variable_dup that dups the string while in the mutex protection? I realize in the core case this will require the caller to then free the returned memory, but this is better than getting a bad pointer. This is analogous to the switch_channel_get_variable and it’s _dup implementation, although it dups it to session memory.<br>
<br>
Switch_channel_get_variable’s ability to peak through to the core variables is susceptible to this. If a core variable is changed after switch_channel_get_variable looks it up but before it dups to the session pool, it’ll have a bad pointer. <br>
<font color="#888888">
<br>
Kevin Snow<br>
Ooma, Inc</font></span></font>
</div>
<br>_______________________________________________<br>
FreeSWITCH-dev mailing list<br>
<a href="mailto:FreeSWITCH-dev@lists.freeswitch.org">FreeSWITCH-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div></div></div>