[asterisk-dev] ast_read() called with no recorded file descriptor. (reulsting in a loop causing: memory leak/high CPU usage)

[Julien Chavanton]

I think I have found more information about this problem crashing the server.
 
I have faced twice on different installation/service completely different, on each of them there is a timeout absolute involved, this is probably why on a few face this problem. it is probably a glare condition, there is only little chances of facing this problem everything a timeout is triggered.
Seems like some handle is destroyed and ast_read() is looping.
 
Set(TIMEOUT(absolute)=${MAXTIME})
 
I will make sure to grab the "T" extension everywhere, maybe this will help ?

________________________________

From: Julien Chavanton
Sent: Tue 06/07/2010 1:04 PM
To: Julien Chavanton; asterisk-dev at lists.digium.com
Subject: RE: ast_read() called with no recorded file descriptor. (reulsting in a loop causing: memory leak/high CPU usage)


Ate least we may have find why this was trigerred, I believe it is either Glare signaling condition or missuse of "t" extenstion.
 
Personaly I never use this extension to grab digits since Read(), Background() and WaitExten() all have duration limit.
 
t: Timeout. Used for when calls have been inactive after a prompt was played. Also used to hang up a line that has been idle. 
 
Is it safe to use this extension for digit capture looks like problematic from what  I have seen ?

________________________________

From: Julien Chavanton
Sent: Mon 05/07/2010 7:41 PM
To: asterisk-dev at lists.digium.com
Cc: Julien Chavanton
Subject: ast_read() called with no recorded file descriptor. (reulsting in a loop causing: memory leak/high CPU usage)



Hi, I have faced the following problem, only on some servers where interco/dialplan application are different, resulting in a loop that crash servers.

main/channel.c:         ast_log(LOG_ERROR, "ast_read() called with no recorded file descriptor.\n");

I have read the posts I could find on the list and made some research, I am running asterisk-1.6.0.9
 
but looking at asterisk-1.6.2.0 it seems we are looging this as an error still.
 
I suspect some dead call, cause by glare condition on SIP signaling but even if it was the case, is there a way to protect the server from the loop ?
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100712/4faddd29/attachment-0001.htm