[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:                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-09 17:49 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.


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0014866 100% cpu problem with channel hangup
====================================================================== 

---------------------------------------------------------------------- 
 (0103055) mmichelson (administrator) - 2009-04-09 17:49
 http://bugs.digium.com/view.php?id=14723#c103055 
---------------------------------------------------------------------- 
It doesn't make sense that the main thread would be the one using up the
CPU since all it does is poll forever until it is time to exit. Polling
causes the thread to be inactive and therefore not use CPU.

I think that it is a different Asterisk thread, or more likely a
combination of different Asterisk threads which are contributing to the
high CPU load. Unfortunately GDB is not a very good tool for trying to
isolate which threads are using the most CPU. A better tool for that would
be a profiling tool such as oprofile.

Here's the odd part. If you svn up'd in the 1.4 branch, then that error
message would not be printed anymore because it has been downgraded to a
debug level message. So that means it's not the increased I/O that was
causing the error. It could be that the short-circuiting that occurs in
ast_read is somehow causing the CPU load to spike, or it could be unrelated
to the new error message.

Also, since you are now tracking the exact same issue in two separate bug
reports, I am closing issue http://bugs.digium.com/view.php?id=14868 since it is
a duplicate of this. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-09 17:49 mmichelson     Note Added: 0103055                          
======================================================================