[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:                     acknowledged
Target Version:             1.6.1.0
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-27 14:34 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
has duplicate       0014868 I have 100% CPU usage with a few calls
related to          0014858 [patch] Regular segfault with chan_unistim
====================================================================== 

---------------------------------------------------------------------- 
 (0103838) mmichelson (administrator) - 2009-04-27 14:34
 http://bugs.digium.com/view.php?id=14723#c103838 
---------------------------------------------------------------------- 
aragon: I haven't looked really deeply at
http://bugs.digium.com/view.php?id=14918, but it appears that there
are at least two different issues happening there.

The valgrind output you have on http://bugs.digium.com/view.php?id=14918 doesn't
really seem relevant to
this issue. In fact, it doesn't show anything except for the usual libc
errors that occur on Asterisk's startup, plus a potentially minor problem
regarding transporting SIP NOTIFYs.

Also, this particular issue has nothing to do with r165796. If you look
through the post history here, you'll see that there were two major issues
and one minor issue. The two major issues have been corrected at this
point.

The major issues were

1. 100% CPU usage on hangup
2. Logs spammed with error regarding chan->fdno

The minor issue is that even though the error message has been suppressed,
the circumstances which made that error message appear are still in the
code. This is being considered minor because operation of Asterisk does not
seem to be impeded by the conditions under which the error message is
generated.

This issue is remaining open until I (or someone else) can come up with a
way to make the conditions for that error message disappear. The solutions
I have come up with so far have worked locally, but when tested by other
users (notably SubEclipse (thanks!)) they do not work for various reasons.
My main focus on this issue right now is trying to simulate the proper
conditions here so that I may reproduce the issue. Unfortunately, I cannot
find what the problem is with my latest patch. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-04-27 14:34 mmichelson     Note Added: 0103838                          
======================================================================