]> git.ipfire.org Git - thirdparty/freeswitch.git/commitdiff
freetdm: Remove optimistic sanity check, prints spurious error messages
authorMoises Silva <moy@sangoma.com>
Thu, 16 Feb 2012 21:08:21 +0000 (16:08 -0500)
committerJames Zhang <jzhang@sangoma.com>
Thu, 16 Feb 2012 21:08:21 +0000 (16:08 -0500)
libs/freetdm/src/ftdm_state.c

index 03f2cd8e182357d55e1fc5e41e7fadc607595d2e..c6d45c3c3c3690dbb7bc806b3637cad34f7fc5d5 100644 (file)
@@ -48,12 +48,22 @@ FT_DECLARE(ftdm_status_t) _ftdm_channel_complete_state(const char *file, const c
        ftdm_time_t diff = 0;
        ftdm_channel_state_t state = fchan->state;
 
+#if 0
+       /* I could not perform this sanity check without more disruptive changes. Ideally we should check here if the signaling module completing the state
+       executed a state processor (called ftdm_channel_advance_states() which call fchan->span->state_processor(fchan)) for the state. That is just a 
+          sanity check, as in the past we had at least one bug where the signaling module set the state and then accidentally changed the state to a new one 
+          without calling ftdm_channel_advance_states(), meaning the state processor for the first state was not executed and that lead to unexpected behavior.
+
+          If we want to be able to perform this kind of sanity check it would be nice to add a new state status (FTDM_STATE_STATUS_PROCESSING), the function
+          ftdm_channel_advance_states() would set the state_status to PROCESSING and then the check below for STATUS_NEW would be valid. Currently is not
+          valid because the signaling module may be completing the state at the end of the state_processor callback and therefore the state will still be
+          in STATUS_NEW, and is perfectly valid ... */
        if (fchan->state_status == FTDM_STATE_STATUS_NEW) {
                ftdm_log_chan_ex(fchan, file, func, line, FTDM_LOG_LEVEL_CRIT, 
                                                "Asking to complete state change from %s to %s in %llums, but the state is still unprocessed (this might be a bug!)\n", 
                                                ftdm_channel_state2str(fchan->last_state), ftdm_channel_state2str(state), diff);
-               /* We should probably return here with FTDM_FAIL if we don't see this message in production environments for a while (2012-02-16) */
        }
+#endif
 
        if (fchan->state_status == FTDM_STATE_STATUS_COMPLETED) {
                ftdm_assert_return(!ftdm_test_flag(fchan, FTDM_CHANNEL_STATE_CHANGE), FTDM_FAIL, "State change flag set but state is already completed\n");