| Summary: | ASTERISK-09425: [patch] More than one group@category is allowed | ||
| Reporter: | Gregory Hinton Nietsky (irroot) | Labels: | |
| Date Opened: | 2007-05-11 10:48:46 | Date Closed: | 2007-07-11 19:59:24 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Functions/func_groupcount |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) asterisk-1.4.4.app.c.group.patch | |
| Description: | if im not mistaken this is a problem and is not the expected begavior bellow. a call comes in and its "called" category gets set to the operator the operator transfers the call and its "called" category is set to the user dealing eith the call. should a new call come in the group count would reflect one call for the user and 0 for operator. however what is happening is as follows ... on the transfer a new channel varrible is added for "called" so the couter reflects 1 call for each of the operator and user. calling SET(GROUP(cat)=VAL) allways adds a new variable to the stack never alters the existing value. in addition to this i recived frequent crashes randomly when working on the channel groups. ****** ADDITIONAL INFORMATION ****** The attached patch deletes and frees the existing group variable on the stack and adds the new variable. this reverts it to the behavior of 1.4.1 (tested) | ||
| Comments: | By: Jared Smith (jsmith) 2007-05-14 10:27:31 I'm curious here... can you please explain the reasoning behind your patch? Are you saying that a channel shouldn't be able to be assigned to more than one group? Can you please be more specific about what you mean by "this reverts it to the behavior of 1.4.1"? I know there were some pretty invasive changes to the group counting mechanism, but I don't think we changed the behavior in any way. If so, we'd like to know about it. By: Gregory Hinton Nietsky (irroot) 2007-05-15 04:24:00 in 1.4.1 and others the behavior was as follows ... GRP@CAT1 GRP@CAT2 GRP@CAT3 ... you can have more than one group but only one group in a cat ie the bellow was not allowed. GRP@CAT1 GRP1@CAT1 should you do a SET(GROUP(CAT1)=GRP1) after a SET(GROUP(CAT1)=GRP) the result would be GRP1@CAT1 in 1.4.4 the result is now GRP@CAT1 GRP1@CAT1 with the small feature of stack/memory corruption and a good chance of a seg fault. this patch makes a small change to the handleing that if there is a group set for that cat and you try assign a new group to the cat it will delete and free the old value and push a new value onto the list avoiding the crash and duplicate groups in a cat there is no way with the existing 1.4.4 to change a group it just keeps adding new ones to the list. By: Joshua C. Colp (jcolp) 2007-06-13 13:26:02 Fixed in 1.2 as of revision 69127, 1.4 as of revision 69128, and trunk as of revision 69129. Thanks! | ||