its dupd on the session pool so will be freed when the session gets destroyed. We did recently change a number of places that were safe to use a non dup version of that. I'm sure there are other places, but as long as your code isn't polling full speed on variable values, it should not cause any problems. If you want to get a non duped version you can, but you would need to do some extra work to make sure the value isn't freed before you use it (could be instantly) so some mutexing is required, duping on the pool frees us from this requirement with typically very little memory cost. Its a tradeoff thats usually a win (although not in all cases)

On Oct 2, 2015, at 7:48 AM, Pat Beirne <patb@apphostcanada.ca> wrote:

I'd like to ask a question about switch_channel_get_variable()

In the include/switch_channel, it's a #define with the 3rd field set to TRUE

<code> #define switch_channel_get_variable(_c, _v) switch_channel_get_variable_dup(_c, _v, SWITCH_TRUE, -1) </code>

When I tunnel into the src/switch_channel.c code, it seems that this "TRUE" should invoke the _strdup version, and create a return value taken from the pool

And indeed, my testing shows that every time I call switch_channel_get_variable(), I get a new distinct pointer.......... but..........the return value is "const char*" so I can't free it

And NONE of the sample code shows the return value being free'd; sometimes the return value isn't even assigned.....it's just tested and discarded

for example: newest FS1.6, src/switch_core_state_machine.c, line 264: <code> if (switch_channel_get_variable(session->channel, "recovered") && !switch_channel_test_flag(session->channel, CF_RECOVERED)) { switch_channel_set_flag(session->channel, CF_RECOVERED); </code>

Is this a problem in the code or a problem in my understanding?

Pat