- 14 4月, 2014 3 次提交
-
-
由 Chris Rienzo 提交于
-
由 Chris Rienzo 提交于
FS-6447 --resolve return subscriber-absent platform-code 20 if <dial> is attempted to user that is not registered
-
由 Michael Jerris 提交于
-
- 13 4月, 2014 1 次提交
-
-
由 Peter Olsson 提交于
Upgrade to OpenSSL 1.0.1g in Windows build (Visual Studio 2010 and 2012)
-
- 12 4月, 2014 7 次提交
-
-
由 Travis Cross 提交于
-
由 Travis Cross 提交于
-
由 Travis Cross 提交于
-
由 Travis Cross 提交于
Automated leak detectors find leaked memory on shutdown. Cleaning up after ourselves on shutdown eliminates noise from these reports.
-
由 Travis Cross 提交于
-
由 Travis Cross 提交于
The rc variable here was always initialized but the compiler couldn't see that because of the lack of an unconditional else clause.
-
由 Travis Cross 提交于
We were leaking one event (~539 bytes) for every subscribe packet received with both an "event: as-feature-event" and an authorization header.
-
- 11 4月, 2014 6 次提交
-
-
由 Travis Cross 提交于
FS-353
-
由 Travis Cross 提交于
-
由 James Le Cuirot 提交于
Tested with several libmemcached versions between 0.31 and 1.0.18. Unfortunately the API is extremely volatile and awkward to use. Packaging scripts still need addressing. FS-353
-
由 James Le Cuirot 提交于
Per the automake manual these should go in LIBADD. http://www.gnu.org/software/automake/manual/html_node/Program-and-Library-Variables.html FS-353 Signed-off-by:
Travis Cross <tc@traviscross.com>
-
由 James Le Cuirot 提交于
FS-353 Signed-off-by:
Travis Cross <tc@traviscross.com>
-
由 Peter Olsson 提交于
-
- 10 4月, 2014 5 次提交
-
-
由 Anthony Minessale 提交于
-
由 Anthony Minessale 提交于
-
由 Anthony Minessale 提交于
-
由 Anthony Minessale 提交于
-
由 Chris Rienzo 提交于
-
- 09 4月, 2014 15 次提交
-
-
由 Travis Cross 提交于
The net effect here is the code looks more "regular" and reads more linearly.
-
由 Travis Cross 提交于
Previously we would continue considering phrase actions even after receiving a break action; we would only break on the next input clause. It appears the intent here was to break before the next action.
-
由 Travis Cross 提交于
-
由 Travis Cross 提交于
If we get SWITCH_STATUS_BREAK then we didn't get SWITCH_STATUS_SUCCESS.
-
由 Travis Cross 提交于
We're breaking out of the loop here anyway, so setting done to true is useless.
-
由 Travis Cross 提交于
We were leaking memory when break_on_match was set or when we received back SWITCH_STATUS_BREAK from a callee as we were failing to free field_expanded_alloc.
-
由 Travis Cross 提交于
If pattern is null we're setting it to a non-null value, so this branch will always be taken. Use `git diff -w` or `git log -p -w` to see what's going on in this commit.
-
由 Travis Cross 提交于
In the event of a memory error, we were trying to free a null pointer while leaking the allocation for field_expanded_alloc.
-
由 Travis Cross 提交于
These variables aren't used outside of this for loop, so they should be declared within it.
-
由 Anthony Minessale 提交于
add switch_hashtable_insert_destructor so you can insert a pointer into a hash with a custom destructor and use it in spandsp to fix a leak on reloadxml with the tone_descriptor tables and fix a bunch of random tiny leaks etc
-
由 Anthony Minessale 提交于
-
由 Anthony Minessale 提交于
-
由 Travis Cross 提交于
Prior to this commit, if anything at all went wrong in switch_ivr_phrase_macro_event() we would generate a warning like this: [WARNING] switch_ivr_play_say.c:348 Macro [macro_name]: 'pattern_name' did not match any patterns This is clearly misleading. The natural thing to do on seeing that message is to verify that the language files are there, and that the pattern really does exist in that macro. But none of that was usually the problem. The message would be generated if the language wasn't found, or if the channel had gone away, for example. With this commit, we verify that we actually tried looking for the pattern before displaying the warning about the pattern not matching.
-
由 Travis Cross 提交于
For years we've been generating spurious messages like: [WARNING] switch_ivr_play_say.c:348 Macro [voicemail_ack]: 'saved' did not match any patterns This would happen when the caller hangs up during the playback of certain prompts in the voicemail system where we weren't checking the return value of vm_macro_get(). Looking closely at the log, it's clear we were calling down into switch_ivr_phrase_macro() long after the channel was gone. The message above is also misleading -- switch_ivr_phrase_macro() would have been able to find that pattern just fine, but it never actually looked because the channel was gone. We'll clean up that message in a follow on commit.
-
由 Travis Cross 提交于
If we received an event without a content-type header we were dereferencing a null pointer leading to a seg fault. Reported-by:
Ico <ico@voip-io.org> ESL-90 --resolve
-
- 08 4月, 2014 3 次提交
-
-
由 Travis Cross 提交于
-
由 Anthony Minessale 提交于
-
由 Anthony Minessale 提交于
-