| Summary: | ASTERISK-13565: ERROR[5003]: channel.c:2043 __ast_read: ast_read() called with no recorded file descriptor. | ||
| Reporter: | Ian Anderson (seadweller) | Labels: | |
| Date Opened: | 2009-03-23 08:27:25 | Date Closed: | 2009-08-17 07:59:05 |
| Priority: | Blocker | Regression? | No |
| Status: | Closed/Complete | Components: | Core/Channels |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) 14723_1-4-24.patch ( 1) 14723_1-4-tip.patch ( 2) 14723_combined.patch ( 3) 14723.patch ( 4) asterisk-thread_apply_all_bt_full.txt ( 5) asterisk-thread_apply_all_bt.txt ( 6) dont_waste_cpu_on_hangup.diff ( 7) dont_waste_cpu_on_hangup-188582.diff | |
| 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. | ||
| Comments: | By: Ian Anderson (seadweller) 2009-03-23 08:33:10 Majority of calls are SIP, with a few IAX2 thrown into the mix. Calls in the dialplan are being bounced out to external SIP providers, with some accounting and minor MySQL access being done within the dialplan. EDIT: Edited to add, the error #'s randomly refer to ERRRORs 5003,5627,5650,4503,5625 and a few others I may have missed. By: Ian Anderson (seadweller) 2009-03-23 09:40:45 Edited my logger.conf a few times to stem the flow of error messages. First "logger reload" worked no problem, second edit and reload brought not only Asterisk but my whole system to a screeching halt. Rebooted and have reverted back to 1.4.22. By: Osvaldo A. Prado Jr (jrprado) 2009-03-24 16:56:58 noticed that the problem occurs when running the command "soft hangup" in a call that stopped, it really does not happen in version 1.4.22.2 By: Edward Eastman (whisk) 2009-03-26 04:17:25 I'm also seeing this on a dev machine running CentOS 4.5, after an upgrade from 1.4.23.2 to 1.4.24, so I'm happy to provide access if required. By: Andrew Lindh (andrew) 2009-03-26 12:04:17 I have also seen this error in branch 1.4, but it was caused by an application that was not written correctly. It may just be an old problem that is now being logged as an error. I found the cause was in an app using an ast_waitfor followed by an ast_read. But the app did not correctly check the return status of ast_waitfor (a timout) and issued the ast_read when there was no data to read, and that caused the error to be logged. PS, I'm running Debian. By: Geoff Mina (geoff2010) 2009-03-26 15:32:49 I am seeing this same behaivor in 1.4.24. I just upgraded today. It would appear calls are flowing properly through the system, just making me a bit nervous. By: Frederic Van Espen (freh) 2009-03-27 05:34:36 I'm seeing these messages on 1.6.0.7-rc2 while trying to receive a fax. By: Andrew Lindh (andrew) 2009-03-27 06:22:54 I think your fax issue is the one I reported in bug id ASTERISK-13846 By: Russell Bryant (russell) 2009-03-29 00:17:07 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? By: Russell Bryant (russell) 2009-03-29 00:18:21 Also, another note for seadweller, the number inside of ERROR[<num>] is actually the thread ID of the thread that generated the error message. It's not actually an error ID. By: keeky (keeky) 2009-03-30 02:44:37 Hi, I'm also getting this problem the thing is that my message log get full and the server crash. I change logger.conf not to write anymore to the file. [Mar 30 09:34:23] ERROR[799] channel.c: ast_read() called with no recorded file descriptor. [Mar 30 09:34:23] ERROR[799] channel.c: ast_read() called with no recorded file descriptor. Did you find a fix ? By: Russell Bryant (russell) 2009-03-31 21:05:55 I'm putting this in feedback state, as we need additional configuration details to aid in reproducing this issue. By: subeclipse (subeclipse) 2009-04-01 11:36:13 I get the same error when the Zapateller application is in use: (1.4.24) Executing [s@blacklisted:1] Answer("SIP", "") in new stack Executing [s@blacklisted:2] Wait("SIP", "1") in new stack Executing [s@blacklisted:3] Zapateller("SIP", "") in new stack [Apr 1 08:41:55] ERROR[8312]: channel.c:2043 __ast_read: ast_read() called with no recorded file descriptor. [Apr 1 08:41:55] ERROR[8312]: channel.c:2043 __ast_read: ast_read() called with no recorded file descriptor. Interestingly, in another context I use Zapateller on timeout, it works perfectly. By: Nick Barnes (bcnit) 2009-04-02 09:10:22 I can confirm that this appears to be a problem in SVN-branch-1.6.1-r185127 with ReceiveFax() also (but that it is not a problem in 1.6.0.6) -- Executing [666@inbound:1] Answer("IAX2/666-1052", "") in new stack -- Executing [666@inbound:2] Wait("IAX2/666-1052", "3") in new stack -- Executing [666@inbound:3] Set("IAX2/666-1052", "LOCALSTATIONID=ABC123") in new stack -- Executing [666@inbound:4] NoOp("IAX2/666-1052", "") in new stack -- Executing [666@inbound:5] ReceiveFAX("IAX2/666-1052", "/home/user1/Files/1238680395.2.tif") in new stack [Apr 2 14:53:18] ERROR[26241]: channel.c:2517 __ast_read: ast_read() called with no recorded file descriptor. [Apr 2 14:53:18] ERROR[26241]: channel.c:2517 __ast_read: ast_read() called with no recorded file descriptor. [Apr 2 14:53:18] ERROR[26241]: channel.c:2517 __ast_read: ast_read() called with no recorded file descriptor. [Apr 2 14:53:18] ERROR[26241]: channel.c:2517 __ast_read: ast_read() called with no recorded file descriptor. etc. etc. By: Eldad Ran (eldadran) 2009-04-05 23:13:36 Just upgraded to 1.4.24.1 from 1.4.20.1 and have the same problem, using CentOS 5. I don't use RXFax nor Zapateller. I use AGI, manager API and dial a lot. Can't get any other information from the system as this message clogs anything else. I had to turn off errors to console and file to get the system manageable. right now CPU usage is a problem, looks like I'll downgrade back to the old version. TOP after one hour of work, low call load of about 30 concurrent calls: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5583 root -11 0 303m 16m 4096 S 205 0.4 62:51.48 asterisk By: Eldad Ran (eldadran) 2009-04-05 23:38:17 I've downgraded to 1.4.23.2 and the problem is gone. if that helps in any way. By: Mark Michelson (mmichelson) 2009-04-06 15:59:09 Russell's on vacation, so I've stepped in to take a look at this and see if I can resolve this before he gets back. All the reported cases come from places where ast_read is called following a call to ast_waitfor (as opposed to ast_waitfor_n or ast_waitfor_nandfds). It also appears that in all cases, a return of 0 from ast_waitfor is considered to mean that the channel has data ready to read. I think I may take a lead from Kevin in some recent work of his. Instead of using ast_waitfor, he used ast_waitfor_n. The reason is that it not only allows you to keep track of whether the call timed out, but it also explicitly returns non-NULL if the channel is ready for reading. By: Mark Michelson (mmichelson) 2009-04-06 16:48:27 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 poll 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! By: Digium Subversion (svnbot) 2009-04-08 10:27:10 Repository: asterisk Revision: 186984 U branches/1.4/main/channel.c ------------------------------------------------------------------------ r186984 | mmichelson | 2009-04-08 10:27:09 -0500 (Wed, 08 Apr 2009) | 24 lines Make a couple of changes with regards to a new message printed in ast_read(). "ast_read() called with no recorded file descriptor" is a new message added after a bug was discovered. Unfortunately, it seems there are a bunch of places that potentially make such calls to ast_read() and trigger this error message to be displayed. This commit does two things to help to make this message appear less. First, the message has been downgraded to a debug level message if dev mode is not enabled. The message means a lot more to developers than it does to end users, and so developers should take an effort to be sure to call ast_read only when a channel is ready to be read from. However, since this doesn't actually cause an error in operation and is not something a user can easily fix, we should not spam their console with these messages. Second, the message has been moved to after the check for any pending masquerades. ast_read() being called with no recorded file descriptor should not interfere with a masquerade taking place. This could be seen as a simple way of resolving issue ASTERISK-13565. However, I still want to try to clear out the existing ways of triggering this message, since I feel that would be a better resolution for the issue. ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=186984 By: Digium Subversion (svnbot) 2009-04-08 10:27:42 Repository: asterisk Revision: 186985 _U trunk/ U trunk/main/channel.c ------------------------------------------------------------------------ r186985 | mmichelson | 2009-04-08 10:27:42 -0500 (Wed, 08 Apr 2009) | 30 lines Merged revisions 186984 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r186984 | mmichelson | 2009-04-08 10:26:46 -0500 (Wed, 08 Apr 2009) | 24 lines Make a couple of changes with regards to a new message printed in ast_read(). "ast_read() called with no recorded file descriptor" is a new message added after a bug was discovered. Unfortunately, it seems there are a bunch of places that potentially make such calls to ast_read() and trigger this error message to be displayed. This commit does two things to help to make this message appear less. First, the message has been downgraded to a debug level message if dev mode is not enabled. The message means a lot more to developers than it does to end users, and so developers should take an effort to be sure to call ast_read only when a channel is ready to be read from. However, since this doesn't actually cause an error in operation and is not something a user can easily fix, we should not spam their console with these messages. Second, the message has been moved to after the check for any pending masquerades. ast_read() being called with no recorded file descriptor should not interfere with a masquerade taking place. This could be seen as a simple way of resolving issue ASTERISK-13565. However, I still want to try to clear out the existing ways of triggering this message, since I feel that would be a better resolution for the issue. ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=186985 By: Digium Subversion (svnbot) 2009-04-08 10:28:22 Repository: asterisk Revision: 186986 _U branches/1.6.0/ U branches/1.6.0/main/channel.c ------------------------------------------------------------------------ r186986 | mmichelson | 2009-04-08 10:28:22 -0500 (Wed, 08 Apr 2009) | 37 lines Merged revisions 186985 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r186985 | mmichelson | 2009-04-08 10:27:41 -0500 (Wed, 08 Apr 2009) | 30 lines Merged revisions 186984 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r186984 | mmichelson | 2009-04-08 10:26:46 -0500 (Wed, 08 Apr 2009) | 24 lines Make a couple of changes with regards to a new message printed in ast_read(). "ast_read() called with no recorded file descriptor" is a new message added after a bug was discovered. Unfortunately, it seems there are a bunch of places that potentially make such calls to ast_read() and trigger this error message to be displayed. This commit does two things to help to make this message appear less. First, the message has been downgraded to a debug level message if dev mode is not enabled. The message means a lot more to developers than it does to end users, and so developers should take an effort to be sure to call ast_read only when a channel is ready to be read from. However, since this doesn't actually cause an error in operation and is not something a user can easily fix, we should not spam their console with these messages. Second, the message has been moved to after the check for any pending masquerades. ast_read() being called with no recorded file descriptor should not interfere with a masquerade taking place. This could be seen as a simple way of resolving issue ASTERISK-13565. However, I still want to try to clear out the existing ways of triggering this message, since I feel that would be a better resolution for the issue. ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=186986 By: Digium Subversion (svnbot) 2009-04-08 10:28:50 Repository: asterisk Revision: 186987 _U branches/1.6.1/ U branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r186987 | mmichelson | 2009-04-08 10:28:50 -0500 (Wed, 08 Apr 2009) | 37 lines Merged revisions 186985 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r186985 | mmichelson | 2009-04-08 10:27:41 -0500 (Wed, 08 Apr 2009) | 30 lines Merged revisions 186984 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r186984 | mmichelson | 2009-04-08 10:26:46 -0500 (Wed, 08 Apr 2009) | 24 lines Make a couple of changes with regards to a new message printed in ast_read(). "ast_read() called with no recorded file descriptor" is a new message added after a bug was discovered. Unfortunately, it seems there are a bunch of places that potentially make such calls to ast_read() and trigger this error message to be displayed. This commit does two things to help to make this message appear less. First, the message has been downgraded to a debug level message if dev mode is not enabled. The message means a lot more to developers than it does to end users, and so developers should take an effort to be sure to call ast_read only when a channel is ready to be read from. However, since this doesn't actually cause an error in operation and is not something a user can easily fix, we should not spam their console with these messages. Second, the message has been moved to after the check for any pending masquerades. ast_read() being called with no recorded file descriptor should not interfere with a masquerade taking place. This could be seen as a simple way of resolving issue ASTERISK-13565. However, I still want to try to clear out the existing ways of triggering this message, since I feel that would be a better resolution for the issue. ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=186987 By: Digium Subversion (svnbot) 2009-04-08 10:29:14 Repository: asterisk Revision: 186988 _U branches/1.6.2/ U branches/1.6.2/main/channel.c ------------------------------------------------------------------------ r186988 | mmichelson | 2009-04-08 10:29:14 -0500 (Wed, 08 Apr 2009) | 37 lines Merged revisions 186985 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r186985 | mmichelson | 2009-04-08 10:27:41 -0500 (Wed, 08 Apr 2009) | 30 lines Merged revisions 186984 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r186984 | mmichelson | 2009-04-08 10:26:46 -0500 (Wed, 08 Apr 2009) | 24 lines Make a couple of changes with regards to a new message printed in ast_read(). "ast_read() called with no recorded file descriptor" is a new message added after a bug was discovered. Unfortunately, it seems there are a bunch of places that potentially make such calls to ast_read() and trigger this error message to be displayed. This commit does two things to help to make this message appear less. First, the message has been downgraded to a debug level message if dev mode is not enabled. The message means a lot more to developers than it does to end users, and so developers should take an effort to be sure to call ast_read only when a channel is ready to be read from. However, since this doesn't actually cause an error in operation and is not something a user can easily fix, we should not spam their console with these messages. Second, the message has been moved to after the check for any pending masquerades. ast_read() being called with no recorded file descriptor should not interfere with a masquerade taking place. This could be seen as a simple way of resolving issue ASTERISK-13565. However, I still want to try to clear out the existing ways of triggering this message, since I feel that would be a better resolution for the issue. ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=186988 By: Private Name (falves11) 2009-04-09 17:22:06 I have 100% usage on my asteris, So maybe you hid the issue, but the issue remains. It happens across the board in all versions. By: Mark Michelson (mmichelson) 2009-04-09 17:23:02 falves11: are you using the patch I uploaded? By: Private Name (falves11) 2009-04-09 17:28:34 Yes I was using it. Now I just did a "svn update" and recompiled. I compiled with thread debug and no optimize. I tried to debug the thread that had all the CPU, and I always got the same data, in 1.4 or 1.6.2 0x00000039c94c92e6 in poll () from /lib64/libc.so.6 (gdb) bt #0 0x00000039c94c92e6 in poll () from /lib64/libc.so.6 #1 0x000000000043deb7 in monitor_sig_flags (unused=0x0) at asterisk.c:3024 #2 0x00000000004402ca in main (argc=3, argv=0x7fffebf11868) at asterisk.c:3705 #3 0x00000039c941d8b4 in __libc_start_main () from /lib64/libc.so.6 #4 0x000000000041ac69 in SSL_accept () ASTERISK-1 0x00007fffebf11858 in ?? () ASTERISK-2 0x0000000000000000 in ?? () (gdb) bt full #0 0x00000039c94c92e6 in poll () from /lib64/libc.so.6 No symbol table info available. #1 0x000000000043deb7 in monitor_sig_flags (unused=0x0) at asterisk.c:3024 p = {fd = 24, events = 1, revents = 0} a = 0 #2 0x00000000004402ca in main (argc=3, argv=0x7fffebf11868) at asterisk.c:3705 c = -1 filename = "/root/.asterisk_history", '\0' <repeats 56 times> hostname = "s252", '\0' <repeats 59 times> tmp = "\003\000\000\000\000\000\000\0003\rU\000\000\000\000\000\020~\000\000\000\000\000~\000\000\000\000\000\022\000\000\000\000~\000\000\000\000\000`\026\177\000\000IPC\000\000\000\000\000`\026\177\000\000\020LC\000\000\000\000" xarg = 0x0 x = 3 f = (FILE *) 0x12bf4660 sigs = {__val = {134238211, 0 <repeats 15 times>}} num = 0 isroot = 1 buf = 0x100000001 <Address 0x100000001 out of bounds> runuser = 0x82ea80 "root" rungroup = 0x82fa80 "root" remotesock = 0x0 __PRETTY_FUNCTION__ = "main" __func__ = "main" #3 0x00000039c941d8b4 in __libc_start_main () from /lib64/libc.so.6 No symbol table info available. #4 0x000000000041ac69 in SSL_accept () No symbol table info available. ASTERISK-1 0x00007fffebf11858 in ?? () No symbol table info available. ASTERISK-2 0x0000000000000000 in ?? () No symbol table info available. By: subeclipse (subeclipse) 2009-04-09 17:48:53 Applied the patch, and I'm no longer getting the error, but the problem is not fixed either. In my case, I was seeing this when Zapateller was being executed by my blacklisted context. With the patch installed, the error is not displayed, but the special information tones cannot be heard when Zapateller is executed. By: Mark Michelson (mmichelson) 2009-04-09 17:49:25 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 ASTERISK-13932 since it is a duplicate of this. By: Private Name (falves11) 2009-04-09 19:20:36 The issue perdists. Is there any way to know for sure what is causing asterisk to use 70% of each of my 4 cores? with less tha 40 calls By: Private Name (falves11) 2009-04-09 19:26:22 I run ps axum -C asterisk and get the thread id or process id that shows the highest value in CPU. Then I grab that number and run gdb /usr/sbin/asterisk pid, and I gte this: (gdb) bt full #0 0x00000039c94c92e6 in poll () from /lib64/libc.so.6 No symbol table info available. #1 0x000000000043df17 in canary_thread (unused=0x71ba0000) at asterisk.c:3051 canary_stat = {st_dev = 0, st_ino = 46912519077056, st_nlink = 0, st_mode = 1908015104, st_uid = 0, st_gid = 1582507856, pad0 = 32767, st_rdev = 4720793, st_size = 0, st_blksize = 248190374611, st_blocks = 1908015104, st_atim = {tv_sec = 140734775895936, tv_nsec = 0}, st_mtim = {tv_sec = 4448023, tv_nsec = 140734775895936}, st_ctim = {tv_sec = 0, tv_nsec = 73014444032}, __unused = {8320864, 4294967307, 17}} now = {tv_sec = 140734775895824, tv_usec = 4699371} __PRETTY_FUNCTION__ = "Invalid Entity" #2 0x000000000044032a in ao2_bt () at astobj2.c:94 c = 1582509696 i = 32767 addresses = {0x698fe90, 0x7fff5e532c91, 0x11, 0x57bf10, 0x14, 0x7fff5e532c90, 0x7fff5e532d30, 0x41ad8b, 0x7fff5e532d50, 0x57bec6, 0x2ada4d457fd0, 0x39c921abc0, 0x39c9750720, 0x1004197c3, 0x39c9750820, 0x69926c4, 0x7fff5e532dc0, 0x82ff20, 0x82ef20, 0x0} strings = (char **) 0x39c921abc0 __PRETTY_FUNCTION__ = "\000\000\216ãC\000" #3 0x00000039c941d8b4 in __libc_start_main () from /lib64/libc.so.6 No symbol table info available. #4 0x000000000041acc9 in jb_choose_impl (chan=Cannot access memory at address 0xffffffffffffffc8 ) at abstract_jb.c:181 jb = (struct ast_jb *) Cannot access memory at address 0xffffffffffffffd8 (gdb) bt #0 0x00000039c94c92e6 in poll () from /lib64/libc.so.6 #1 0x000000000043df17 in canary_thread (unused=0x71ba0000) at asterisk.c:3051 #2 0x000000000044032a in ao2_bt () at astobj2.c:94 #3 0x00000039c941d8b4 in __libc_start_main () from /lib64/libc.so.6 #4 0x000000000041acc9 in jb_choose_impl (chan=Cannot access memory at address 0xffffffffffffffc8 ) at abstract_jb.c:181 Previous frame inner to this frame (corrupt stack?) By: Private Name (falves11) 2009-04-09 19:51:48 I just uploaded the "thread apply all bt" command, which may show what is happenning. With 28 calls it is on 1.5 cores, 3 GHZ each core. By: Private Name (falves11) 2009-04-09 20:42:40 Now with 30 open calls it eats 3 Cores of 3 GHZ each. A total of 9 GHZ. it does not have an 'h' extensions. I just uploaded a new file with thread apply all bt full. It shows exactly what every thread is doing. In that time Asterisk was eating 4 full cores with almost no calls. By: Private Name (falves11) 2009-04-11 11:19:14 I had to go back in all my machines to SVN-branch-1.4-r168975, which does not have the 100% CPU issue. But I would like to keep current. Is there any technique to detect what happens? The issue happens across all branches, so it was something added to all of them at some point. It is not related to timing=internal, etc. I tried both. After a while the processor's usage goes up and stays up even if there are no calls open. By: Tilghman Lesher (tilghman) 2009-04-12 22:34:49 Since this is a CPU usage issue, obtaining a callgrind output from "valgrind --tool=callgrind --log-file=asterisk asterisk -vvvcg" may be helpful. By: Private Name (falves11) 2009-04-12 22:44:53 I cannot use Valgrind in production. I would get fired. If you can produce a patch with some tracing to a flat file, I will implement it. Thr problem happens fairly quickly By: Fernando Lujan (flujan) 2009-04-13 14:10:20 After the patch, the ChanSpy app stop working. The bridge channel is muted. By: Mark Michelson (mmichelson) 2009-04-13 14:18:41 One thing I just thought about was the fact that the natural assumption here is that the error message seen is directly correlated to the high CPU usage. @falves11: Since you say this happens fairly quickly, would you mind doing a small experiment? First try using Asterisk 1.4 rev 179536. See if the problem occurs. Next, change to revision 179741. See if the problem occurs there, too. This may help to narrow the range of revisions at which this problem occurs. Thanks! Also thanks to those who have reported problems with the patch I posted. Apparently it is not correct as is and needs additional work. By: Private Name (falves11) 2009-04-13 18:18:14 This machine has the issue so far: Asterisk SVN-branch-1.4-r179741 built by root @ s252 on a x86_64 running Linux on 2009-04-13 21:51:57 UTC Please email me if you want to log in and take a look. venefax gmail By: Private Name (falves11) 2009-04-13 19:58:45 Installed 2 machines earlier with 179741 and both got the issue. By: Andriy I Pylypenko (bamby) 2009-04-14 09:56:44 I'm experiencing this issue also. My asterisk originates call, then after some conversation, peer hangs up and with some probability the channel hangs forever eating 100% CPU and killing disk space with the log message 'ast_read() called with no recorded file descriptor'. On my system this happened several times in an hour. I've analyzed the possible cause of the issue and it seems the r179608 brought in the problem. The patch seems to effectively disable the code where AST_CONTROL_HANGUP frame is processed and so prevents the channel from being hanged up. I've commented out this change and now my two asterisks have been working fine for several hours. I'm attaching my patch for everyone who needs it. Hope it could help. P.S. I've tried the 14723.patch but with no luck. The messages stop to waste the disk space, but the looping of the channel doesn't stop. P.P.S. I'm sorry, I've tried the recently committed change to logging. But I haven't tried the 14723.patch By: Private Name (falves11) 2009-04-14 10:10:30 I will wait until the marshals apply the patch to all the branches. But thanks a lot. This is the isue. By: Mark Michelson (mmichelson) 2009-04-14 10:16:42 Thanks for the patch bamby! It's not likely that the code you commented out will just be removed. It seems like there are certain circumstances under which we should ignore the problem reported in that error message. I'll see if I can isolate the specific circumstances. By: Mark Michelson (mmichelson) 2009-04-14 13:09:16 Changing out of the feedback state since we have received excellent feedback. Thanks everyone. By: Private Name (falves11) 2009-04-15 16:09:33 Bambi's patch fails to work on version SVN-branch-1.4-r188582 patch -p0 < dont_waste_cpu_on_hangup.diff patching file main/channel.c Hunk #1 FAILED at 2038. 1 out of 1 hunk FAILED -- saving rejects to file main/channel.c.rej By: Andriy I Pylypenko (bamby) 2009-04-16 01:11:23 I've attached my patch against revision 188582. By: Mark Michelson (mmichelson) 2009-04-16 09:59:22 I think bamby's patch has the right idea. We need to make sure to make it to the zombie/hangup check before reporting the problem of no recorded file descriptor. Rather than just comment out the offending section, I will instead move it to a portion of ast_read after we have checked for pending masquerades and after we have checked for zombie/hangup. I will make a patch against 1.4.24 and a patch against the current 1.4 branch tip. By: Mark Michelson (mmichelson) 2009-04-16 10:04:11 I have uploaded two patches, 14723_1-4-24.patch, and 14723_1-4-tip.patch. The former is a patch made against 1.4.24, and the latter is a patch made against rev 188646 of 1.4. My assumption is that if bamby's patch was working for people, this should, too. Please let me know if it helps. By: Private Name (falves11) 2009-04-16 10:05:44 I think all the versions, 1.6.1 and 1.6.2 have the same 100% CPU issue. Please apply the same patch to all the branches. By: Mark Michelson (mmichelson) 2009-04-16 10:11:36 Yes, if it is determined that this patch fixes the problem, the fix will be merged to trunk and all 1.6.X branches. By: subeclipse (subeclipse) 2009-04-16 10:57:44 Applied 14723_1-4-24.patch to 1.4.24, still getting the error: -- Executing [s@blacklisted:1] Answer("SIP/5555555555", "") in new stack -- Executing [s@blacklisted:2] Wait("SIP/5555555555", "1") in new stack -- Executing [s@blacklisted:3] Zapateller("SIP/5555555555", "") in new stack [Apr 16 08:37:42] ERROR[18438]: channel.c:2058 __ast_read: ast_read() called with no recorded file descriptor. [Apr 16 08:37:42] ERROR[18438]: channel.c:2058 __ast_read: ast_read() called with no recorded file descriptor. By: Private Name (falves11) 2009-04-16 11:04:15 I see a patch for 1.4.24, but when I try this: svn co http://svn.digium.com/svn/asterisk/branches/1.4.24 asterisk it says that it does not exist. How do I get the very latest of the 1.4.X branch? By: Mark Michelson (mmichelson) 2009-04-16 11:09:36 @falves: if you want the latest tagged release of 1.4, then svn co http://svn.digium.com/svn/asterisk/tags/1.4.24 If you want the tip of the 1.4 branch (which includes more recent changes than what is in 1.4.24) then svn co http://svn.digium.com/svn/asterisk/branches/1.4 @SubEclipse: Thanks. I should have been more clear with the intentions of the latest patch I uploaded. The idea behind it is to try to get rid of the 100% CPU problem that seems to occur on hangups, due to the introduction of the message. I realize that simply moving the message to a new place won't stop it from appearing during normal operation. I think something like the first patch I uploaded (14723.patch) is necessary to make those messages stop appearing. Apparently, though, the first patch I uploaded needs some work though since people have reported that zapateller and chanspy are no longer functioning properly with that patch applied. By: subeclipse (subeclipse) 2009-04-16 11:41:30 Thanks... I've rolled back to 1.4.21.2 for now. By: Mark Michelson (mmichelson) 2009-04-17 15:30:27 @SubEclipse: you reported hearing no audio for Zapateller when you tried the first patch I uploaded. What type of channel were you using to call into Asterisk? By: subeclipse (subeclipse) 2009-04-17 15:39:06 Yes, that is correct... Applying 14723.patch suppresses the error, but no audio is heard. SIP Channel. By: Mark Michelson (mmichelson) 2009-04-17 15:51:58 Well, dang. I was trying to figure out why it could be that you weren't hearing audio with that patch applied. I have tested the patch using SIP phones and I do hear audio from the Zapateller application. Of course, then again, I was never seeing the error message to begin with. By: Andriy I Pylypenko (bamby) 2009-04-18 02:28:06 I've been testing the 14723_1-4-24.patch for about a day and no more looping occurs, so I can confirm the patch fixes the problem. Thanks for the fix mmichelson! By: Private Name (falves11) 2009-04-18 12:07:01 I have been testing the patch for 1.4 tip and it works fine. Congratulations. By: Private Name (falves11) 2009-04-19 17:33:55 is it added to 1.6.2 yet? I need to use that version. Many thanks. By: Mark Michelson (mmichelson) 2009-04-20 08:57:52 I'm a bit torn over what to do about this issue. First of all, the 100% CPU issue appears to be solved with the latest set of patches uploaded. A big thanks to falves for narrowing down what revisions caused the problem and to bamby for stating the reason why the issue was occurring. This, to me, is the biggest issue that has been solved here. Since I consider this to be a large issue, I will commit the fix to all branches of Asterisk. There is also the issue of the error message constantly appearing on the console for certain people. Going back to ~102335, the important thing to remember is that the error message is what's new, not the behavior causing the error message. I have committed a patch to all branches of Asterisk which has demoted this message to be a debug message instead of an error. On one hand, I feel as if this is suitable as a fix since the applications in question are working fine. I also realize that the behavior which would cause that message to appear should be fixed. My plan for now is to keep this bug open while I attempt to figure out why certain applications appear to be causing more trouble than others. One issue I will be looking at closely is ASTERISK-13846, posted by andrew. Several users have switched to it and found that the error message has gone when they use the faxing applications. I have changed this from "ready for review" to "acknowledged" since I am still looking into this. By: Digium Subversion (svnbot) 2009-04-20 09:04:42 Repository: asterisk Revision: 189277 U branches/1.4/main/channel.c ------------------------------------------------------------------------ r189277 | mmichelson | 2009-04-20 09:04:41 -0500 (Mon, 20 Apr 2009) | 12 lines Move the check for chan->fdno == -1 to after the zombie/hangup check. Many users were finding that their hung up channels were staying up and causing 100% CPU usage. (issue ASTERISK-13565) Reported by: seadweller Patches: 14723_1-4-tip.patch uploaded by mmichelson (license 60) Tested by: falves11, bamby ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189277 By: Digium Subversion (svnbot) 2009-04-20 09:05:28 Repository: asterisk Revision: 189278 _U trunk/ U trunk/main/channel.c ------------------------------------------------------------------------ r189278 | mmichelson | 2009-04-20 09:05:28 -0500 (Mon, 20 Apr 2009) | 18 lines Merged revisions 189277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r189277 | mmichelson | 2009-04-20 09:04:41 -0500 (Mon, 20 Apr 2009) | 12 lines Move the check for chan->fdno == -1 to after the zombie/hangup check. Many users were finding that their hung up channels were staying up and causing 100% CPU usage. (issue ASTERISK-13565) Reported by: seadweller Patches: 14723_1-4-tip.patch uploaded by mmichelson (license 60) Tested by: falves11, bamby ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189278 By: Digium Subversion (svnbot) 2009-04-20 09:05:53 Repository: asterisk Revision: 189279 _U branches/1.6.0/ U branches/1.6.0/main/channel.c ------------------------------------------------------------------------ r189279 | mmichelson | 2009-04-20 09:05:53 -0500 (Mon, 20 Apr 2009) | 25 lines Merged revisions 189278 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r189278 | mmichelson | 2009-04-20 09:05:27 -0500 (Mon, 20 Apr 2009) | 18 lines Merged revisions 189277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r189277 | mmichelson | 2009-04-20 09:04:41 -0500 (Mon, 20 Apr 2009) | 12 lines Move the check for chan->fdno == -1 to after the zombie/hangup check. Many users were finding that their hung up channels were staying up and causing 100% CPU usage. (issue ASTERISK-13565) Reported by: seadweller Patches: 14723_1-4-tip.patch uploaded by mmichelson (license 60) Tested by: falves11, bamby ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189279 By: Digium Subversion (svnbot) 2009-04-20 09:06:50 Repository: asterisk Revision: 189280 _U branches/1.6.1/ U branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r189280 | mmichelson | 2009-04-20 09:06:49 -0500 (Mon, 20 Apr 2009) | 25 lines Merged revisions 189278 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r189278 | mmichelson | 2009-04-20 09:05:27 -0500 (Mon, 20 Apr 2009) | 18 lines Merged revisions 189277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r189277 | mmichelson | 2009-04-20 09:04:41 -0500 (Mon, 20 Apr 2009) | 12 lines Move the check for chan->fdno == -1 to after the zombie/hangup check. Many users were finding that their hung up channels were staying up and causing 100% CPU usage. (issue ASTERISK-13565) Reported by: seadweller Patches: 14723_1-4-tip.patch uploaded by mmichelson (license 60) Tested by: falves11, bamby ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189280 By: Digium Subversion (svnbot) 2009-04-20 09:07:14 Repository: asterisk Revision: 189281 _U branches/1.6.2/ U branches/1.6.2/main/channel.c ------------------------------------------------------------------------ r189281 | mmichelson | 2009-04-20 09:07:14 -0500 (Mon, 20 Apr 2009) | 25 lines Merged revisions 189278 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r189278 | mmichelson | 2009-04-20 09:05:27 -0500 (Mon, 20 Apr 2009) | 18 lines Merged revisions 189277 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r189277 | mmichelson | 2009-04-20 09:04:41 -0500 (Mon, 20 Apr 2009) | 12 lines Move the check for chan->fdno == -1 to after the zombie/hangup check. Many users were finding that their hung up channels were staying up and causing 100% CPU usage. (issue ASTERISK-13565) Reported by: seadweller Patches: 14723_1-4-tip.patch uploaded by mmichelson (license 60) Tested by: falves11, bamby ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=189281 By: Mark Michelson (mmichelson) 2009-04-20 09:08:49 @falves: To answer your question more directly, the note directly above this one shows that I committed 14723_1-4-tip.patch to the 1.6.2 branch. By: Mark Michelson (mmichelson) 2009-04-20 10:52:10 Looking at andrew's patch on 14769, there were two main things he has done: 1. He has increased the timeout on the ast_waitfor call from 20 ms to 50 ms. 2. He has changed the ast_waitfor such that on a return of 0, it will continue. Item (1) is something that makes good sense; however I can't think of any other place in Asterisk that uses a timeout that low. Item (2) is more like what I was attempting to do in my first patch I uploaded here. I see some flaws in the first patch I uploaded. I will attempt a new patch and upload it as soon as it is ready. By: Mark Michelson (mmichelson) 2009-04-20 15:26:48 I have uploaded a new patch, called 14723_combined.patch. This patch was created against 1.4.24, and is meant to be tested by those using 1.4.24. The reason the name contains the word "combined" is that this has both the fix for the 100% CPU problem in it (previously posted as 14723_1-4-24.patch) and a fix which should correct the continuous output of the error message. @SubEclipse: I think I know why Zapateller was not playing audio for you with the first patch I uploaded on this issue. The tonepair generator in Asterisk waits for 100 ms for the channel to be ready to be read from. In my first patch, if the 100 ms should expire, we would consider that a failure. In my new patch, if the 100 ms expires, then we retry the waiting. I have confidence that you will not experience the same problem you did with the first patch I supplied. @flujan: Similarly, I see why ChanSpy was not working at all with the previous patch I supplied. I tested ChanSpy with the new patch and it worked fine for me. By: Mark Michelson (mmichelson) 2009-04-23 12:51:41 Any test results yet? By: Fernando Lujan (flujan) 2009-04-23 15:11:21 That is it... I am not having the issue and Chanspy is working. :) Congrats and thanks for the patch. By: Mark Michelson (mmichelson) 2009-04-23 16:52:50 Thanks for the feedback flujan. I'm really interested in finding out if I am correct about Zapateller as well. Unfortunately, I can't reproduce the problem locally, even with the first patch I posted, so I would like to hear from SubEclipse or someone else who had experienced the problem. By: subeclipse (subeclipse) 2009-04-24 14:18:30 Sorry, I've been swamped. I just applied the new patch, and unfortunately the problem still exists. Zapateller is launched, but no audio is heard (no error is displayed either)... the call does not progress to the next line in extensions.conf (I assume it's looping through your new functionality). -- Executing [s@blacklisted:1] Answer("SIP/5555555555-0896d310", "") in new stack -- Executing [s@blacklisted:2] Wait("SIP/5555555555-0896d310", "1") in new stack -- Executing [s@blacklisted:3] Zapateller("SIP/5555555555-0896d310", "") in new stack By: Mark Michelson (mmichelson) 2009-04-24 15:11:13 Thanks for the feedback, SubEclipse. If we're not progressing toward the next line in the dialplan, I would suspect that you are correct and that the waitfor() loop in the tonepair generator is not being interrupted properly. So, here are some new questions for you: 1. Do you have DAHDI or Zaptel installed on this system? 2. Do you have the internal_timing option enabled in asterisk.conf? 3. Do you have silence suppression enabled on the phone you are using to test? By: subeclipse (subeclipse) 2009-04-24 19:32:13 1.) Zaptel 2.) No 3.) Testing from cell phone By: Mark Michelson (mmichelson) 2009-04-27 11:45:18 Thanks for the feedback, SubEclipse. I'm changing the status of this issue back to "acknowledged." By: David Brillert (aragon) 2009-04-27 12:47:31 I am seeing similar notices in two of my open bug reports. I also have a looping problem which effects my sites differently. The loop appears in different places ie. IVR, ACD, wake up call. I have valgrind posted on http://bugs.digium.com/view.php?id=14918 We have revert r165796 on 1.4.24.1 in order to have working AGI and IVR audio on bug report http://bugs.digium.com/view.php?id=14843 IMHO there must be some relation between these three tickets and possibly all are related to r165796 or that revisions' root cause. Perrhaps the root cause is the high CPU load caused by what is seen in 14723... By: Mark Michelson (mmichelson) 2009-04-27 14:34:46 aragon: I haven't looked really deeply at ASTERISK-13971, but it appears that there are at least two different issues happening there. The valgrind output you have on ASTERISK-13971 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. By: Mark Michelson (mmichelson) 2009-04-27 14:46:13 SubEclipse: I still have been unable to reproduce the error messages from the use of Zapateller, nor have I been able to make the code loop when using my latest patch on this issue. I've been using the following very simple dialplan to test: exten => 1,1,Answer exten => 1,n,Wait(1) exten => 1,n,Zapateller() exten => 1,n,Hangup Would you mind uploading a small sample dialplan which exhibits the looping behavior you saw when using the latest patch I uploaded? Thanks. By: David Brillert (aragon) 2009-04-27 14:56:27 mmichelson I understand what you are saying about 14723 not being related to my other two tickets and the reason for which this ticket is still open. As for any relationship between the three cases I definitely correlated an increase in these messages "utils.c:938 ast_carefulwrite: Timed out trying to write" with increased CPU load and with the increased CPU load my applications started to fail randomly (and by random I mean you could never tell which application would fail on any given server). Reverting r165796 fixed my IVR issues in 14843 but did not decrease the CPU load on that server. Suffice to say that the symptoms of 14918 are exactly like those I saw in 14843. And I am crossing my fingers that a fix for 14723 will calm the CPU enough to remove the other issues. I'll keep any future comments restricted to my other two open tickets. By: subeclipse (subeclipse) 2009-04-27 18:09:46 Your example works for me as well, it's only when used with the blacklist function that I encounter this (I think I mentioned this in my 1st or 2nd post, but I may have been vague... sorry about that). exten => 5555555555,1,GotoIf(${BLACKLIST()}?blacklisted,s,1) [blacklisted] exten => s,1,Answer() exten => s,n,Wait(1) exten => s,n,Zapateller() exten => s,n,Hangup() By: Leif Madsen (lmadsen) 2009-05-04 13:45:10 Changing back to assigned as someone has replied back with a dialplan that may exhibit this issue. By: Mark Michelson (mmichelson) 2009-05-08 08:20:08 I tried using that dialplan when it was posted and could not reproduce the problem. Also, I could have sworn I posted a note saying so, too. Oh well, my mistake. By: Mark Michelson (mmichelson) 2009-05-08 08:24:21 Oops, sorry about that. I didn't mean to close this report :) By: Joshua C. Colp (jcolp) 2009-05-19 15:07:36 I spent some time today tracking down why the message would still be coming up in certain scenarios and believe I have narrowed it down to ast_waitfor being used and the poll being interrupted. This seems fine and doesn't cause any issues to occur. I haven't been able to recreate the issue though where some scenarios (like Zapateller) unfortunately. By: caspy (caspy) 2009-05-29 05:31:15 after upgrade from 1.6.0.6 to 1.6.0.9 i started to observe topic messages: [May 29 14:10:49] ERROR[9168]: channel.c:2520 __ast_read: ast_read() called with no recorded file descriptor. is there any way to discover what module/part of code is involved in error? By: caspy (caspy) 2009-06-11 04:23:35 is there any ways or ideas regarding detection of place where this error (see my comment 0105710) originated? By: jmls (jmls) 2009-06-19 10:19:55 Just for the record, I hit this bug as well. I've just updated to svn head, and will post further results. By: Private Name (falves11) 2009-06-19 10:23:50 I think this bug may be related to https://issues.asterisk.org/view.php?id=15356 By: Private Name (falves11) 2009-06-19 18:16:59 Using the current verision (201679) of 1.6.2, after a few hours working fine, I typed "core show channels count" and it locked up. It stopped processing calls. By: Digium Subversion (svnbot) 2009-07-20 11:26:28 Repository: asterisk Revision: 207360 U branches/1.4/main/channel.c ------------------------------------------------------------------------ r207360 | russell | 2009-07-20 11:26:27 -0500 (Mon, 20 Jul 2009) | 9 lines Only do the chan->fdno check in ast_read() in a developer build. I changed this check to only happen in a dev-mode build. I also added a comment explaining what is going on. I also made it so that detection of this situation does not affect ast_read() operation. (closes issue ASTERISK-13565) Reported by: seadweller ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=207360 By: Digium Subversion (svnbot) 2009-07-20 11:36:18 Repository: asterisk Revision: 207361 _U trunk/ U trunk/main/channel.c ------------------------------------------------------------------------ r207361 | russell | 2009-07-20 11:36:17 -0500 (Mon, 20 Jul 2009) | 16 lines Merged revisions 207360 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines Only do the chan->fdno check in ast_read() in a developer build. I changed this check to only happen in a dev-mode build. I also added a comment explaining what is going on. I also made it so that detection of this situation does not affect ast_read() operation. (closes issue ASTERISK-13565) Reported by: seadweller ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=207361 By: Digium Subversion (svnbot) 2009-07-20 11:37:56 Repository: asterisk Revision: 207362 _U branches/1.6.0/ U branches/1.6.0/main/channel.c ------------------------------------------------------------------------ r207362 | russell | 2009-07-20 11:37:56 -0500 (Mon, 20 Jul 2009) | 23 lines Merged revisions 207361 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r207361 | russell | 2009-07-20 11:36:15 -0500 (Mon, 20 Jul 2009) | 16 lines Merged revisions 207360 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines Only do the chan->fdno check in ast_read() in a developer build. I changed this check to only happen in a dev-mode build. I also added a comment explaining what is going on. I also made it so that detection of this situation does not affect ast_read() operation. (closes issue ASTERISK-13565) Reported by: seadweller ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=207362 By: Digium Subversion (svnbot) 2009-07-20 11:40:12 Repository: asterisk Revision: 207363 _U branches/1.6.1/ U branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r207363 | russell | 2009-07-20 11:40:12 -0500 (Mon, 20 Jul 2009) | 23 lines Merged revisions 207361 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r207361 | russell | 2009-07-20 11:36:15 -0500 (Mon, 20 Jul 2009) | 16 lines Merged revisions 207360 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines Only do the chan->fdno check in ast_read() in a developer build. I changed this check to only happen in a dev-mode build. I also added a comment explaining what is going on. I also made it so that detection of this situation does not affect ast_read() operation. (closes issue ASTERISK-13565) Reported by: seadweller ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=207363 By: Digium Subversion (svnbot) 2009-07-20 11:42:02 Repository: asterisk Revision: 207364 _U branches/1.6.2/ U branches/1.6.2/main/channel.c ------------------------------------------------------------------------ r207364 | russell | 2009-07-20 11:42:02 -0500 (Mon, 20 Jul 2009) | 23 lines Merged revisions 207361 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r207361 | russell | 2009-07-20 11:36:15 -0500 (Mon, 20 Jul 2009) | 16 lines Merged revisions 207360 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines Only do the chan->fdno check in ast_read() in a developer build. I changed this check to only happen in a dev-mode build. I also added a comment explaining what is going on. I also made it so that detection of this situation does not affect ast_read() operation. (closes issue ASTERISK-13565) Reported by: seadweller ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=207364 | ||