Merged revisions 313588 via svnmerge from

https://origsvn.digium.com/svn/asterisk/branches/1.8

................
  r313588 | rmudgett | 2011-04-13 11:31:50 -0500 (Wed, 13 Apr 2011) | 55 lines
  
  Merged revisions 313579 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.6.2
  
  ................
    r313579 | rmudgett | 2011-04-13 11:29:49 -0500 (Wed, 13 Apr 2011) | 48 lines
    
    Merged revisions 313545 via svnmerge from 
    https://origsvn.digium.com/svn/asterisk/branches/1.4
    
    ........
      r313545 | rmudgett | 2011-04-13 11:21:24 -0500 (Wed, 13 Apr 2011) | 41 lines
      
      Asterisk does not hangup a channel after endpoint hangs up.
      
      If the call that the dialplan started an AGI script for is hungup while
      the AGI script is in the middle of a command then the AGI script is not
      notified of the hangup.  There are many AGI Exec commands that this can
      happen with.  The reported applications have been: Background, Wait, Read,
      and Dial.  Also the AGI Get Data command.
      
      * Don't wait on the Asterisk channel after it has hung up.  The channel is
      likely to never need servicing again.
      
      * Restored the AGI script's ability to return the AGI_RESULT_HANGUP value
      in run_agi().  It previously only could return AGI_RESULT_SUCCESS or
      AGI_RESULT_FAILURE after the DeadAGI and AGI applications were merged.
      
      (closes issue #17954)
      Reported by: mn3250
      Patches:
            issue17954_v1.8.patch uploaded by rmudgett (license 664)
            issue17954_v1.6.2.patch uploaded by rmudgett (license 664)
            issue17954_v1.4.patch uploaded by rmudgett (license 664)
      Tested by: rmudgett
      JIRA SWP-2171
      
      (closes issue #18492)
      Reported by: devmod
      Tested by: rmudgett
      JIRA SWP-2761
      
      (closes issue #18935)
      Reported by: nvitaly
      Tested by: astmiv, rmudgett
      JIRA SWP-3216
      
      (closes issue #17393)
      Reported by: siby
      Tested by: rmudgett
      JIRA SWP-2727
      
      Review: https://reviewboard.asterisk.org/r/1165/
    ........
  ................
................


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313606 65c4cc65-6c06-0410-ace0-fbb531ad65f3

1 files changed, 19 insertions, 15 deletions

diff --git a/main/channel.c b/main/channel.c
index c3b3981f1..6a422673a 100644
--- a/main/channel.c
+++ b/main/channel.c
@@ -3722,23 +3722,27 @@ static struct ast_frame *__ast_read(struct ast_channel *chan, int dropaudio)
 		} else {
 			goto done;
 		}
-	}
-
+	} else {
 #ifdef AST_DEVMODE
-	/* 
-	 * The ast_waitfor() code records which of the channel's file descriptors reported that
-	 * data is available.  In theory, ast_read() should only be called after ast_waitfor()
-	 * reports that a channel has data available for reading.  However, there still may be
-	 * some edge cases throughout the code where ast_read() is called improperly.  This can
-	 * potentially cause problems, so if this is a developer build, make a lot of noise if
-	 * this happens so that it can be addressed. 
-	 */
-	if (chan->fdno == -1) {
-		ast_log(LOG_ERROR,
-			"ast_read() on chan '%s' called with no recorded file descriptor.\n",
-			chan->name);
-	}
+		/*
+		 * The ast_waitfor() code records which of the channel's file
+		 * descriptors reported that data is available.  In theory,
+		 * ast_read() should only be called after ast_waitfor() reports
+		 * that a channel has data available for reading.  However,
+		 * there still may be some edge cases throughout the code where
+		 * ast_read() is called improperly.  This can potentially cause
+		 * problems, so if this is a developer build, make a lot of
+		 * noise if this happens so that it can be addressed.
+		 *
+		 * One of the potential problems is blocking on a dead channel.
+		 */
+		if (chan->fdno == -1) {
+			ast_log(LOG_ERROR,
+				"ast_read() on chan '%s' called with no recorded file descriptor.\n",
+				chan->name);
+		}
 #endif
+	}
 
 	prestate = chan->_state;