bridge_basic.c: Make sure that ast_bridge_channel is not destroyed while iterating...

From the gdb information, we can see that while iterating over bridge->channels, the ast_bridge_channel reference count is 0, indicating it has already been destroyed.Additionally, when ast_bridge_channel is removed from bridge->channels, the bridge is first locked. Therefore, locking the bridge before iterating over bridge->channels can resolve the race condition.

Resolves: https://github.com/asterisk/asterisk/issues/768

diff --git a/main/bridge_basic.c b/main/bridge_basic.c
index 952ac9f3804a1865eafda96fffef68ebee40954f..1451250dfa632beaaf82f06df28faed34fe686a2 100644 (file)
--- a/main/bridge_basic.c
+++ b/main/bridge_basic.c
@@ -1851,7 +1851,9 @@ static void bridge_ringing(struct ast_bridge *bridge)
                .subclass.integer = AST_CONTROL_RINGING,
        };
 
+       ast_bridge_lock(bridge);
        ast_bridge_queue_everyone_else(bridge, NULL, &ringing);
+       ast_bridge_unlock(bridge);
 }
 
 /*!
@@ -1864,7 +1866,9 @@ static void bridge_hold(struct ast_bridge *bridge)
                .subclass.integer = AST_CONTROL_HOLD,
        };
 
+       ast_bridge_lock(bridge);
        ast_bridge_queue_everyone_else(bridge, NULL, &hold);
+       ast_bridge_unlock(bridge);
 }
 
 /*!
@@ -1877,7 +1881,9 @@ static void bridge_unhold(struct ast_bridge *bridge)
                .subclass.integer = AST_CONTROL_UNHOLD,
        };
 
+       ast_bridge_lock(bridge);
        ast_bridge_queue_everyone_else(bridge, NULL, &unhold);
+       ast_bridge_unlock(bridge);
 }
 
 /*!