Re: [asterisk-dev] [Code Review] 4178: res_pjsip_outbound_publish: stack overflow when using non-default sorcery wizard

[Matt Jordan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4178/#review13781
---



branches/13/res/res_pjsip_outbound_publish.c


Given that this small function is only called by 
ast_sip_publish_client_get, I think the entire thing could be moved to that 
function.



branches/13/res/res_pjsip_outbound_publish.c


Rather than forward declaring this, you could simply move the function to 
this spot. Since it is logically the 'destruction callback' for state objects, 
it probably belongs with the rest of the state-specific functions anyway.



branches/13/res/res_pjsip_outbound_publish.c


This returns an int, but currently always returns 0. That's fine, since 
this is a callback function for an ao2_callback, and there isn't much we can do.

However, if states or state is not valid, we should at least log an ERROR, 
as things will be in an extremely "bad" state at that point.



branches/13/res/res_pjsip_outbound_publish.c


This is a common anti-pattern to slip into that is dangerous.

There's no guarantee that states is non-NULL after the call to 
ao2_global_obj_ref(current_states) - you could be in a module unload, the 
container has been destroyed, and somehow this function gets called.

Any time you have a global container, you have to check that it is valid 
before using it. This should be:

struct ast_sip_outbound_publish_client *state;

if (!states) {
return -1;
}

state = ao2_find(...)



branches/13/res/res_pjsip_outbound_publish.c


I'm with Richard on this: I think it's almost always better to break up the 
allocation and the validity check - particularly for long and complex 
allocations.

new_state = ao2_container_alloc(...);
if (!new_state) {

}



branches/13/res/res_pjsip_outbound_publish.c


I don't really like the pattern that we have here.

We technically have two destructor functions:
 * sip_outbound_publish_client_destroy, which destroys the state object
 * destroy_old_state, which must only be called on a state object once just 
prior to it being destroyed

That feels wrong. I would expect that destroy_old_state should just be a 
part of sip_outbound_publish_client_destroy.

If sip_outbound_publish_client_destroy actually is the only destructor for 
the object, *and* the container holds the last reference for the object 
(assuming it isn't being used elsewhere, in which case reference counting will 
still work just fine), the you should be able to just destroy the container. 
That will remove the container's reference to its objects, which will cause 
their destruction.



branches/13/res/res_pjsip_outbound_publish.c


This is unsafe, as previously noted. states can be NULL.



branches/13/res/res_pjsip_outbound_publish.c


Break up allocation.



branches/13/res/res_pjsip_outbound_publish.c


This is another reason to unify the destructors of the state objects: this 
will cause the current_states container to be destroyed, without fist calling 
destroy_old_state on the objects:

ao2_callback(current_states, OBJ_NODATA | OBJ_UNLINK, destroy_old_state, 
NULL);


- Matt Jordan


On Nov. 13, 2014, 2:08 p.m., Kevin Harwell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4178/
> ---
> 
> (Updated Nov. 13, 2014, 2:08 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24514
> https://issues.asterisk.org/jira/browse/ASTERISK-24514
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When using a non-default sorcery wizard (in this instance realtime) for 
> outbound publishes Asterisk will crash after a stack overflow occurs due to 
> the code infinitely recursing.  The fix entails removing the outbound publish 
> state dependency from the outbound publish sorcery object and instead keeping 
> an in memory container that can be used to lookup the state when needed.
> 
> 
> Diffs
> -
> 
>   branches/13/res/res_pjsip_outbound_publish.c 427787 
> 
> Diff: https://reviewboard.asterisk.org/r/4178/diff/
> 
> 
> Testing
> ---
> 
> On top of running the current testsuite tests I also manu

Re: [asterisk-dev] [Code Review] 4172: Testsuite: tests for res_pjsip_config_wizard

[Matt Jordan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4172/#review13782
---



asterisk/trunk/tests/channels/pjsip/config_wizard/AMISendTest.py


You can at least append your name here :-)



asterisk/trunk/tests/channels/pjsip/config_wizard/AMISendTest.py


There's a good chance this will throw an exception if there is no ACTION in 
the config. How about:

action = self.config.get('ACTION')
if not action:
return

...


- Matt Jordan


On Nov. 11, 2014, 4:45 p.m., George Joseph wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4172/
> ---
> 
> (Updated Nov. 11, 2014, 4:45 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> These are the tests for res_pjsip_config_wizard 
> https://reviewboard.asterisk.org/r/4165/
> 
> When I cloned AMISendTest, I made a small change that might be usefull for 
> other AMI tests...  You now specify the ACTION in test-config.yaml rather 
> than having ACTION hard coded in AMISendTest.py and the results in 
> test-config.yaml.
> 
> 
> Diffs
> -
> 
>   asterisk/trunk/tests/channels/pjsip/tests.yaml 5920 
>   asterisk/trunk/tests/channels/pjsip/config_wizard/trunk/test-config.yaml 
> PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/trunk/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   asterisk/trunk/tests/channels/pjsip/config_wizard/tests.yaml PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/registration/test-config.yaml
>  PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/registration/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   asterisk/trunk/tests/channels/pjsip/config_wizard/phone/test-config.yaml 
> PRE-CREATION 
>   
> asterisk/trunk/tests/channels/pjsip/config_wizard/phone/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   asterisk/trunk/tests/channels/pjsip/config_wizard/AMISendTest.py 
> PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/4172/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4145: testsuite: update pretty_print script for recent runtests.py changes.

[Matt Jordan]

> On Nov. 4, 2014, 4:53 p.m., Mark Michelson wrote:
> > Why the change to being a standalone script? I personally like the idea of 
> > it being a filter more.
> 
> George Joseph wrote:
> I changed it locally months back for 2 reasons...
> The first was that runtests wasn't pre-calculating and printing the total 
> number of tests to run back then.  So I had to run runtests twice, once to 
> get the total number (in dry-run mode) then again for real.
> 
> The other one was buffering problems.  ./runtests.py | pretty_print 
> wasn't printing output as often as it should so I was always doing
> python -u ./runtests.py | pretty_print.
> 
> Honestly, I didn't think anyone else was using it. :)
> 
> I can change it back to a filter if that's more useful.
> 
> 
>

Now that I know it exists I'm going to be using it more often :-)

Personally, I like that it is a filter. I think that's kinda helpful - and the 
outpupt is certainly much nicer to look at then the current output from 
runtests when just running a subset of tests.

We could modify runtests.py to output things unbuffered (or possibly to 
unbuffer things with a particular command line switch) - something like this 
perhaps:

http://stackoverflow.com/questions/881696/unbuffered-stdout-in-python-as-in-python-u-from-within-the-program


- Matt


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4145/#review13673
---


On Nov. 3, 2014, 9:43 a.m., George Joseph wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4145/
> ---
> 
> (Updated Nov. 3, 2014, 9:43 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Updated contrib/scripts/pretty_print so it works with recent runtests.py 
> changes.  Also changed it from a filter to a standalone script.
> 
> 
> Diffs
> -
> 
>   asterisk/trunk/contrib/scripts/pretty_print 5878 
> 
> Diff: https://reviewboard.asterisk.org/r/4145/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4145: testsuite: update pretty_print script for recent runtests.py changes.

[George Joseph]

> On Nov. 4, 2014, 3:53 p.m., Mark Michelson wrote:
> > Why the change to being a standalone script? I personally like the idea of 
> > it being a filter more.
> 
> George Joseph wrote:
> I changed it locally months back for 2 reasons...
> The first was that runtests wasn't pre-calculating and printing the total 
> number of tests to run back then.  So I had to run runtests twice, once to 
> get the total number (in dry-run mode) then again for real.
> 
> The other one was buffering problems.  ./runtests.py | pretty_print 
> wasn't printing output as often as it should so I was always doing
> python -u ./runtests.py | pretty_print.
> 
> Honestly, I didn't think anyone else was using it. :)
> 
> I can change it back to a filter if that's more useful.
> 
> 
>
> 
> Matt Jordan wrote:
> Now that I know it exists I'm going to be using it more often :-)
> 
> Personally, I like that it is a filter. I think that's kinda helpful - 
> and the outpupt is certainly much nicer to look at then the current output 
> from runtests when just running a subset of tests.
> 
> We could modify runtests.py to output things unbuffered (or possibly to 
> unbuffer things with a particular command line switch) - something like this 
> perhaps:
> 
> 
> http://stackoverflow.com/questions/881696/unbuffered-stdout-in-python-as-in-python-u-from-within-the-program

Easily changed.  Stay tuned.


- George


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4145/#review13673
---


On Nov. 3, 2014, 8:43 a.m., George Joseph wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4145/
> ---
> 
> (Updated Nov. 3, 2014, 8:43 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Updated contrib/scripts/pretty_print so it works with recent runtests.py 
> changes.  Also changed it from a filter to a standalone script.
> 
> 
> Diffs
> -
> 
>   asterisk/trunk/contrib/scripts/pretty_print 5878 
> 
> Diff: https://reviewboard.asterisk.org/r/4145/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3867: [chan_sip] Default DTLS settings to use if peer misses own settings

[Michael K.]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3867/
---

(Updated Nov. 15, 2014, 10:31 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 427950


Bugs: ASTERISK-24128
https://issues.asterisk.org/jira/browse/ASTERISK-24128


Repository: Asterisk


Description
---

Load default dtls settings from [general settings]
If peer has dtls enabled but misses some of the settings and they are set in 
default settings it would load them from there.
It would be logical as most of sip settings work like that and as well as there 
is no way to use template in realtime and it would lead to copy paste same 
settings for every peer.


Diffs
-

  trunk/channels/chan_sip.c 419849 

Diff: https://reviewboard.asterisk.org/r/3867/diff/


Testing
---

Test on development server (ast 11.11.0)


Thanks,

Michael K.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 3980: cel_odbc: Add microseconds precision in the eventtime column

[Etienne Lessard]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3980/
---

(Updated Nov. 15, 2014, 10:51 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 427952


Bugs: ASTERISK-24283
https://issues.asterisk.org/jira/browse/ASTERISK-24283


Repository: Asterisk


Description
---

This patch adds microsecond precision when inserting a CEL record into a table 
with an "eventtime" column of type timestamp, instead of second precision. The 
documentation (configs/cel_odbc.conf.sample) was already saying that the 
eventtime column included microseconds precision, but that was not the case.

Also, without this patch, if you had a table with an "eventtime" column of type 
varchar, you had millisecond precision. With this patch, you also get 
microsecond precision in this case.


Diffs
-

  /branches/11/cel/cel_odbc.c 422682 

Diff: https://reviewboard.asterisk.org/r/3980/diff/


Testing
---

Tested with postgres 9.1 and mysql 5.5.

With postgres, with a CEL table with an "eventtime" column of type timestamp, 
you get microsecond precision. Same for a CEL table with an "eventtime" column 
of type varchar.

With mysql, with a CEL table with an "eventtime" column of type timestamp, you 
still get only second precision, because mysql 5.5 don't store it ( 
http://dev.mysql.com/doc/refman/5.5/en/fractional-seconds.html ). That said, 
it's not causing any problem. For a CEL table with an "eventtime" column of 
type varchar, you do get microsecond precision.


Thanks,

Etienne Lessard

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4145: testsuite: update pretty_print script for recent runtests.py changes.

[George Joseph]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4145/
---

(Updated Nov. 15, 2014, 12:05 p.m.)


Review request for Asterisk Developers.


Changes
---

Changed back to filter.   Run with ./runtests.py  | 
contrib/scripts/pretty_print
Added time current test has been running.
Added total run time to final summary.
Changed runtests.py to re-open stdout in single line buffered mode.
Changed runtests.py to print total number of tests that will be run before 
actually running any tests.  This allows_pretty print to tell you where in the 
test run you are.

Example:
# ./runtests.py -t tests/channels/pjsip/ami
Running tests for Asterisk 12.8.0
 ...

Tests to run: 9
--> Running test 'tests/channels/pjsip/ami/pjsip_notify/content' ...

etc.


Repository: testsuite


Description
---

Updated contrib/scripts/pretty_print so it works with recent runtests.py 
changes.  Also changed it from a filter to a standalone script.


Diffs (updated)
-

  asterisk/trunk/runtests.py 5927 
  asterisk/trunk/contrib/scripts/pretty_print 5927 

Diff: https://reviewboard.asterisk.org/r/4145/diff/


Testing
---


Thanks,

George Joseph

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] [Code Review] 4186: stringfields: Fix regression from fix for unintentional memory retention and another issue exposed by the fix

[Corey Farrell]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4186/
---

Review request for Asterisk Developers and rmudgett.


Repository: Asterisk


Description
---

This addresses a regression in the previous fix that applies to all versions.  
When __ast_string_field_ptr_grow is called by 
ast_string_field_ptr_set_by_fields, it needs to be passed &target, not __p__.  
In the current code if __ast_string_field_ptr_grow actually does anything, it 
will cause *__p__ != target.  Unfortunately in this case *__p__ points to the 
new address, target to the old.  This may cause too much data to be written to 
the old space for the string, and this could cause memory corruption.  This was 
the first thing I noticed when attempting to troubleshoot 
res/parking/dynamic_parking_variables unit test failure, but did not fix the 
test.

Also needed to get the unit test working again is a fix for 
ast_string_fields_copy in 12+.  The existing code relies on the fact that 
__ast_string_field_release_active never previously zeroed pool->used, so 
keeping the existing pointer was ok.  Setting each field to 
__ast_string_field_empty after releasing the memory seems to resolve the issue.


Diffs
-

  /branches/12/include/asterisk/stringfields.h 427735 

Diff: https://reviewboard.asterisk.org/r/4186/diff/


Testing
---

Not enough, so far I've only verified this change with the unit test brought to 
my attention by Richard.  I'll be running the full testsuite ASAP, but wanted 
to allow this code to be seen now.


Thanks,

Corey Farrell

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4166: testsuite: tests/bridge/bridge_action leaves a channel open

[Corey Farrell]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4166/
---

(Updated Nov. 15, 2014, 2:37 p.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


Repository: testsuite


Description
---

self.channels[3] is not hung up, causing the Asterisk graceful shutdown to 
timeout.  This causes the test to fail under REF_DEBUG mode and prevents 
coverage from seeing the code executed by this test.


Diffs
-

  /asterisk/trunk/tests/bridge/bridge_action/bridge_action.py 5920 

Diff: https://reviewboard.asterisk.org/r/4166/diff/


Testing
---


Thanks,

Corey Farrell

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4166: testsuite: tests/bridge/bridge_action leaves a channel open

[Corey Farrell]

> On Nov. 13, 2014, 11:30 a.m., Mark Michelson wrote:
> > With the fix being made to the leaked bridge in Asterisk, is this change 
> > still required? Does hanging up self.channels[1] not result in 
> > self.channels[3] and the bridge being destroyed as expected?
> 
> Corey Farrell wrote:
> Still required, I'm guessing that when the first channel hangs up it 
> leaves the second in a single user bridge.  I'm not sure if this is a bug in 
> Asterisk or just the way it works.  The XMLDOC doesn't specify.
> 
> Corey Farrell wrote:
> Actually on further inspection it appears the bridge is destroyed, and 
> the caller is sent back to the previous Dialplan location.  core show 
> channels without hangup of self.channels[3]:
> Channel  Location State   Application(Data)   
>   
> Local/waiting_area@d (None)   Up  Echo()  
>   
> Local/waiting_area@d (None)   Up  Echo()  
>   
> 2 active channels
> 2 active calls
> 14 calls processed
> 
> If I then run 'channel request hangup 
> Local/waiting_area@default-0003;1' (or hangup ;2), the test finishes and 
> passes leak free.
> 
> This is strange to me, why all the other channel pairs were hung up but 
> not this one.
> 
> Mark Michelson wrote:
> There are a few of unique properties to the final bridge that, imo, 
> shouldn't affect operations but in practice might:
> 
> 1) The final bridge between 1 and 3 is the only one where the remaining 
> channel in the bridge came from another bridge rather than directly from the 
> dialplan. In fact, the remaining channel had been in two previous bridges, so 
> its movement through the bridges may have something to do with it.
> 2) The final bridge between 1 and 3 is the only one where a channel is 
> hung up. In the other cases, a channel is stolen from the bridge, resulting 
> in bridge dissolution.
> 
> After looking at the code again in action_bridge in features.c, the 
> channels that are bridged together have ast_bridge_set_after_go_on() set on 
> them. Looking at the docs for ast_bridge_set_after_go_on(), it says "If 
> parseable_goto, then use the given context/exten/priority as the relative 
> position for the parseable goto. Else goto the given 
> context/exten/priorit+1". We don't provide a parseable goto, so after 
> becoming unbridged, the channels should move to the next priority in the 
> dialplan after the one they're currently in. Since the channels being bridged 
> are currently at the Echo() priority, they should be returned to the dialplan 
> at the next priority, which is Hangup(). This happens with all but channel 3. 
> Somehow, I'm guessing that some code path is causing the priority number to 
> goto after the bridge to get screwed up, so it ends up back in Echo() instead 
> of moving on to Hangup().
> 
> I think this is a problem in Asterisk, not the test.

Joshua just pointed out ASTERISK-24020, looks like this is already a reported 
issue against Asterisk.  I'm discarding this review since we've determined the 
testsuite it not at fault.


- Corey


---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4166/#review13745
---


On Nov. 11, 2014, 3:37 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4166/
> ---
> 
> (Updated Nov. 11, 2014, 3:37 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> self.channels[3] is not hung up, causing the Asterisk graceful shutdown to 
> timeout.  This causes the test to fail under REF_DEBUG mode and prevents 
> coverage from seeing the code executed by this test.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/bridge/bridge_action/bridge_action.py 5920 
> 
> Diff: https://reviewboard.asterisk.org/r/4166/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4145: testsuite: update pretty_print script for recent runtests.py changes.

[George Joseph]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4145/
---

(Updated Nov. 15, 2014, 3:36 p.m.)


Review request for Asterisk Developers.


Changes
---

runtests.py:
Changed to re-open stdout in single line buffered mode.
Changed to print total number of tests that will be run before actually running 
any tests.  This allows_pretty print to tell you where in the test run you are.
Changed to add a '--timeout n' parameter.  If a test fails to output anything 
within n seconds, the test is aborted.  The default is inf so without the 
parameter the behavior is the same as today.  The status printed will be 
'timedout' instead of 'passed' or 'failed'.

pretty-print:
Changed back to filter.   Run with ./runtests.py  | 
contrib/scripts/pretty_print
Added time current test has been running.
Added total run time to final summary.
Added 'timedout' to the possible statuses.


Repository: testsuite


Description
---

Updated contrib/scripts/pretty_print so it works with recent runtests.py 
changes.  Also changed it from a filter to a standalone script.


Diffs (updated)
-

  asterisk/trunk/runtests.py 5927 
  asterisk/trunk/contrib/scripts/pretty_print 5927 

Diff: https://reviewboard.asterisk.org/r/4145/diff/


Testing
---


Thanks,

George Joseph

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] [Code Review] 4145: testsuite: update pretty_print script for recent runtests.py changes.

[George Joseph]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4145/
---

(Updated Nov. 15, 2014, 4:57 p.m.)


Review request for Asterisk Developers.


Changes
---

Made a few more visual tweaks for keeping track of timeouts.


Repository: testsuite


Description
---

Updated contrib/scripts/pretty_print so it works with recent runtests.py 
changes.  Also changed it from a filter to a standalone script.


Diffs (updated)
-

  asterisk/trunk/runtests.py 5927 
  asterisk/trunk/contrib/scripts/pretty_print 5927 

Diff: https://reviewboard.asterisk.org/r/4145/diff/


Testing
---


Thanks,

George Joseph

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev