[asterisk-bugs] [Asterisk 0018862]: Free parking slot logic broken if randomising start - stops early and doesn't recognize it failed (#16428 is not complete fix)

Wed May 18 12:57:52 CDT 2011

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18862 
====================================================================== 
Reported By:                davidw
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18862
Category:                   Features/Parking
Reproducibility:            have not tried
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                       SWP-3156 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 307231 
Request Review:              
====================================================================== 
Date Submitted:             2011-02-21 12:52 CST
Last Modified:              2011-05-18 12:57 CDT
====================================================================== 
Summary:                    Free parking slot logic broken if randomising start 
- stops early and doesn't recognize it failed
(https://issues.asterisk.org/view.php?id=16428 is not complete fix)
Description: 
https://issues.asterisk.org/view.php?id=16428 fixes a bug relating to the exit
conditions for the free parking
slot search, but only does so if the start of the search is not randomised
(R option on ParkAndAnnounce()).

It stops the search when it hits the end of the range, not when it has
wrapped back to the starting point.

The subsequent code only properly handles the no free slot case when it
stops after going right round.  I haven't followed through, but I think
there is a potential crash downstream.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016428 [patch] park() function takes 100% of CPU
====================================================================== 

---------------------------------------------------------------------- 
 (0135103) davidw (reporter) - 2011-05-18 12:57
 https://issues.asterisk.org/view.php?id=18862#c135103 
---------------------------------------------------------------------- 
This was picked up when looking at the code for another reason, so there
isn't actually live output or dialplan to support it.

However, the obvious failures is that, except in the degenerate case, any
free parking slots below the random starting point will not be considered
as being available.

However, the code will actually assume that it did find something.  As I
noted, I didn't follow that through, but it looks to leave it with a
pointer to something it shouldn't own.

It looks as though the issue is still there in trunk.

Basically this bug is being approached from a static analysis of the
code.

I suspect the reason it doesn't show up in the field is everyone simply
invokes extension 700, or the feature code, so Park is never run with the R
option set.  I think a lot of people don't actually realise that 700 is
just a system generated dialplan entry for Park with no options.

To try and provoke it, I think one would specify a parking lot with two
(might need three) entries, then put 

exten => ????,1,Park(,,,R)

in the dialplan and call it multiple times, from different devices.  To
break, with three slots, the third slot has to already have been taken and
random has to land on it.  On the first iteration, i will point to the
third slot.  As it is filled, the list traverse will set cur.  It will then
go round the loop, with i pointing beyond the end.  The first if will set i
to before the beginning. and the break will terminate the for loop.  The if
outside the loop will compare the second slot position with the slot before
the first's position, and not match, so will not report a problem and not
exit with NULL.  parking_space will be set to i, which will be one before
the start of the parking lot, and the code will try to proceed with that
bogus parking slot entry, even if it in use for other purposes (typically
the Park call), or was found by a previous cycle of this process. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-05-18 12:57 davidw         Note Added: 0135103                          
======================================================================