| Summary: | ASTERISK-05923: [patch] [memory leak] in res_features.c | ||
| Reporter: | Luigi Rizzo (rizzo) | Labels: | |
| Date Opened: | 2005-12-29 04:14:27.000-0600 | Date Closed: | 2006-01-05 16:09:38.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Resources/res_features |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 20060105__bug6081.diff.txt | |
| Description: | res_features.c::do_parking_thread() near the block sending manager event "ParkedCallGiveUp" has a potential memory leak, because the frame that is possibly read is not freed. Fix is trivial, add "if (f) ast_frfree(f);" within the block. On passing: res_features.c::feature_exec_app() near the end sets res = -2 if the application is not found, but then ignores it and returns success. If it is safe to ignore the error then the assigment is useless; otherwise, res should be reported up. Also on passing - near the beginning of ast_park_call there is a doubly nested loop on parking_range and the parkinglot list. What exactly is this trying to achieve, find the smallest unused number in the parking range ? Then things could be made a lot simpler eg by keeping the parking lot sorted by extension. This piece of code has O(N^2) complexity, with a large (say 1000) parking range with lots of parked calls, you can easily spend ages looping in here. | ||
| Comments: | By: Luigi Rizzo (rizzo) 2005-12-29 04:18:23.000-0600 whoops... sorry put the wrong category! [is there a way to edit your own reports to fix this kind of mistakes ?] By: Clod Patry (junky) 2005-12-29 08:52:08.000-0600 You can't change category until you are a bug marshall. By: Tilghman Lesher (tilghman) 2006-01-05 16:09:19.000-0600 Fixed in 1.2, merged to trunk | ||