[asterisk-dev] [Code Review]: Pickup segfault when multiple pickups of multiple localchan calls

[mjordan]

> On Aug. 5, 2011, 9:15 a.m., mjordan wrote:
> > trunk/include/asterisk/features.h, line 123
> > <https://reviewboard.asterisk.org/r/1353/diff/1/?file=17718#file17718line123>
> >
> >     Provide a doxygen comment with \brief, \param, and \returns fields
> 
> Alec Davis wrote:
>     It's just debug code and can go

For all of your 'debug' statements, either:

1) If its debug code, it shouldn't be in a review, and it shouldn't be checked in.  Please remove the code and post a new diff for review.
2) If its not debug code - and generally, I wouldn't assume a new ast_* method is debug, then it needs to follow the Asterisk coding standards.


> On Aug. 5, 2011, 9:15 a.m., mjordan wrote:
> > trunk/include/asterisk/channelstate.h, line 46
> > <https://reviewboard.asterisk.org/r/1353/diff/1/?file=17717#file17717line46>
> >
> >     Adding a new channel state seems like it would have a rather large impact.  What tests have you done to ensure that adding a new state a channel can be in doesn't impact any other Asterisk dialplan functions or applications?
> >     
> >     Fix comment as well to be "Line is being picked up"
> 
> Alec Davis wrote:
>     seen the . before Line.
>     
>

I'm not sure what you mean by this.  Your comment appears to have a typo in it, unless iLine is an object I'm not aware of.

Regardless, you didn't address the major point here, which is that a new channel state has a lot of impacts.  Have you run this through the Asterisk test suite?  Or added any tests that ensures a regression wasn't introduced?


- mjordan


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


On Aug. 5, 2011, 2:37 p.m., Alec Davis wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1353/
> -----------------------------------------------------------
> 
> (Updated Aug. 5, 2011, 2:37 p.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Summary
> -------
> 
> The weird issue is why isn't the pickup datastore added to a local channel not working as it should.
> 
> This an attempt to fix Asterisk SVN-trunk-r330650 but perhaps the wrong approach.
>  
>  
> 
> If ast_can_pickup() can pickup the channel, it needs to change the chan->_state to AST_STATE_PICKUP.
> 
> Example dialplan below causes a segfault as ast-hangup removes the same channel as is being picked up.
> 
> How to crash it!
>   dial 801 from 1 phone.
>   from 2 phones simultaneously dial 800.
>   segfault!
> 
> exten => 801,1,NoOp(Local pickup debug: Ring Phones) 
> exten => 801,n,Dial(Local/823 at en-phone&Local/824 at en-phone)
> 
> exten => 800,1,NoOp(Local pickup: Pickup through Localchan call)
> exten => 800,n,Dial(Local/824 at en-pickup&Local/823 at en-pickup)
> 
> [en-pickup]
> exten => _[0-9*#]!, 1, PickupChan(Local/${EXTEN}@en-phone)
> 
> [en-phone]
> exten => _[0-9*#]!, 1, Dial(SIP/gxp-${EXTEN},20,rwt)
> 
> will remove red blobs, and perhaps ast_pickup_active() test.
> 
> 
> This addresses bug ASTERISK-18222.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18222
> 
> 
> Diffs
> -----
> 
>   trunk/include/asterisk/channelstate.h 330704 
>   trunk/include/asterisk/features.h 330704 
>   trunk/main/channel.c 330704 
>   trunk/main/features.c 330704 
> 
> Diff: https://reviewboard.asterisk.org/r/1353/diff
> 
> 
> Testing
> -------
> 
> Party A ring in which triggers off 2 internal localchan calls, as per 801 in the example dialplan.
> Party B and Party C, attempt to pickup the same calls, using 800 in the example dialplan.
> 
> There is another senario thats not right, before even applying this patch.
> Party A ring in, which again triggers 2 internal localchan calls as per 801 in dialplan.
> Party B and Party C, use *8 to pickup. We then have a NULL OBJ message on screen, and an orpaned channel.
> 
> 
> Thanks,
> 
> Alec
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110805/fde5e083/attachment.htm>