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

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=14723 
====================================================================== 
Reported By:                seadweller
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   14723
Category:                   Core/Channels
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
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-03-29 00:17 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.


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

---------------------------------------------------------------------- 
 (0102335) russell (administrator) - 2009-03-29 00:17
 http://bugs.digium.com/view.php?id=14723#c102335 
---------------------------------------------------------------------- 
First of all, if you are now seeing this message after upgrading, don't
panic.  It's a new error message in 1.4.24.  So, it's likely that whatever
is causing it to get printed has always happened and is not actually
causing a problem.  So, don't panic.  :-)  However, I would like to find
all of the places that trigger this message and fix them.

Can those of you seeing this message provide some more information that
may help me (or someone else) reproduce it?  Can you provide the dialplan
that is being executed?  Also, how are the calls being originated?  Are
they just normal incoming calls, or are call files, AMI originate, or some
other method being used? 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-29 00:17 russell        Note Added: 0102335                          
======================================================================