[asterisk-bugs] [Asterisk 0014723]: ERROR[5003]: channel.c:2043 __ast_read: ast_read() called with no recorded file descriptor.

[Asterisk Bug Tracker]

The following issue is now READY FOR TESTING. 
====================================================================== 
http://bugs.digium.com/view.php?id=14723 
====================================================================== 
Reported By:                seadweller
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   14723
Category:                   Core/Channels
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     ready for testing
Target Version:             1.4.25
Asterisk Version:           1.4.24 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-03-23 08:27 CDT
Last Modified:              2009-04-06 16:48 CDT
====================================================================== 
Summary:                    ERROR[5003]: channel.c:2043 __ast_read: ast_read()
called with no recorded file descriptor.
Description: 
Performed an upgrade from 1.4.22 to 1.4.24 running on CentOs 4.  Used the
same "slim" configuration that I used in 1.4.22, which worked fine.

Calls are processing, but connecting to the console gets the following:

[Mar 23 13:08:05] ERROR[5003]: channel.c:2043 __ast_read: ast_read()
called with no recorded file descriptor.
[Mar 23 13:08:05] ERROR[5003]: channel.c:2043 __ast_read: ast_read()
called with no recorded file descriptor.

This repeats continuously.  If I issue a show channels, I get some output
and it seems to stop the ERROR messages, though it seems the "show
channels" does not complete.  You can get the CLI command and * will still
be trying to spit out a few channels below it.

The system load is also very high (2.38 with 50 or so concurrent calls),
though CPU usage is low... it must be coming from somewhere else. 
Typically this load under 1.4.22 would show perhaps a 0.2 or 0.3 load.


====================================================================== 

---------------------------------------------------------------------- 
 (0102806) mmichelson (administrator) - 2009-04-06 16:48
 http://bugs.digium.com/view.php?id=14723#c102806 
---------------------------------------------------------------------- 
Based on my theory that we are calling ast_read when the channel is not
actually ready to be read from, I combed through the code and found all the
places that looked troublesome. There were two main courses of action I
took.

1. If -1 is passed as the timeout to ast_waitfor(), it is impossible for a
negative value to be returned. Instead, a 0 return is how an error is
indicated. Yes, it's weird and confusing. So, any place that tried to check
for an error by seeing if the result was < 0 have been changed to an
equivalence comparison to 0.

2. Places where a positive timeout was passed to ast_waitfor should not
try to read from the channel if the result is 0, since it means that the
poll() call on the channel's file descriptors timed out. However, this
isn't really an error either, so we should continue attempting to read from
the channel.

These changes have been uploaded as 14723.patch. This patch was created
against the tip of the 1.4 branch. I'd like to make sure that this method
is helping before taking the time to update the various 1.6 branches with
similar changes. Those of you running 1.4, please let us know if this patch
helps to clear those error messages away. Thanks! 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-06 16:48 mmichelson     Note Added: 0102806                          
2009-04-06 16:48 mmichelson     Status                   acknowledged => ready
for testing
======================================================================