Summary: | ASTERISK-13495: Background leaves files open indefinately | ||
Reporter: | Fredrik Liljegren (fiddur) | Labels: | |
Date Opened: | 2009-02-02 04:57:58.000-0600 | Date Closed: | 2009-02-04 13:45:17.000-0600 |
Priority: | Blocker | Regression? | No |
Status: | Closed/Complete | Components: | Core/PBX |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) 14384.patch ( 1) debugging | |
Description: | After a Background(mysound) the sound file stays open, according to lsof. This leads after a while to a total crippling of asterisk since it can't open any socket, getting "Too many open files" or "Can't create alert pipe!". ****** ADDITIONAL INFORMATION ****** I set category Core/PBX since BackGround is builtin and is in main/pbx.c. | ||
Comments: | By: Fredrik Liljegren (fiddur) 2009-02-03 11:02:23.000-0600 If anyone else is having this problem in a critical environment (yes, I made too few tests before upgrading my production server...), the temporary fix seems to be to raise number of allowed open files and restart asterisk daily or so... I added this to /etc/init.d/asterisk: ulimit -Hn 100000 ulimit -n 100000 By: Mark Michelson (mmichelson) 2009-02-03 16:22:21.000-0600 I know what's wrong here and I have created a fix for this. I'll upload a patch shortly. By: Mark Michelson (mmichelson) 2009-02-03 16:24:16.000-0600 I've uploaded 14384.patch. The fix is so simple that it almost feels too simple, but I understand why it was needed and why the problem did not manifest itself earlier. Please give it a sanity check to be sure that the error is cleared up. Thanks! By: Mark Michelson (mmichelson) 2009-02-03 16:33:28.000-0600 I forgot to switch the status to "ready for testing" when I uploaded the patch. By: Fredrik Liljegren (fiddur) 2009-02-04 00:24:59.000-0600 Yes, it works great! Thank you VERY much, GREAT work! By: Mark Michelson (mmichelson) 2009-02-04 09:23:08.000-0600 Thanks for the feedback. I'll get the patch merged ASAP. By: Digium Subversion (svnbot) 2009-02-04 09:30:13.000-0600 Repository: asterisk Revision: 173354 U trunk/main/file.c ------------------------------------------------------------------------ r173354 | mmichelson | 2009-02-04 09:30:13 -0600 (Wed, 04 Feb 2009) | 30 lines Fix a problem where file playback would cause fds to remain open forever The problem came from the fact that a frame read from a format interpreter was not freed. Adding a call to ast_frfree fixed this. The explanation for why this caused the problem is a bit complex, but here goes: There was a problem in all versions of Asterisk where the embedded frame of a filestream structure was referenced after the filestream was freed. This was fixed by adding reference counting to the filestream structure. The refcount would increase every time that a filestream's frame pointer was pointing to an actual frame of data. When the frame was freed, the refcount would decrease. Once the refcount reached 0, the filestream was freed, and as part of the operation, the open files were closed as well. Thus it becomes more clear why a missing ast_frfree would cause a reference leak and cause the files to not be closed. You may ask then if there was a frame leak before this patch. The answer to that is actually no! The filestream code was "smart" enough to know that since the frame we received came from a format interpreter, the frame had no malloced data and thus didn't need to be freed. Now, however, there is cleanup that needs to be done when we finish with the frame, so we do need to call ast_frfree on the frame to be sure that the refcount for the filestream is decremented appropriately. (closes issue ASTERISK-13495) Reported by: fiddur Patches: 14384.patch uploaded by putnopvut (license 60) Tested by: fiddur, putnopvut ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=173354 By: Digium Subversion (svnbot) 2009-02-04 09:30:55.000-0600 Repository: asterisk Revision: 173355 _U branches/1.6.0/ U branches/1.6.0/main/file.c ------------------------------------------------------------------------ r173355 | mmichelson | 2009-02-04 09:30:55 -0600 (Wed, 04 Feb 2009) | 38 lines Merged revisions 173354 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r173354 | mmichelson | 2009-02-04 09:30:12 -0600 (Wed, 04 Feb 2009) | 30 lines Fix a problem where file playback would cause fds to remain open forever The problem came from the fact that a frame read from a format interpreter was not freed. Adding a call to ast_frfree fixed this. The explanation for why this caused the problem is a bit complex, but here goes: There was a problem in all versions of Asterisk where the embedded frame of a filestream structure was referenced after the filestream was freed. This was fixed by adding reference counting to the filestream structure. The refcount would increase every time that a filestream's frame pointer was pointing to an actual frame of data. When the frame was freed, the refcount would decrease. Once the refcount reached 0, the filestream was freed, and as part of the operation, the open files were closed as well. Thus it becomes more clear why a missing ast_frfree would cause a reference leak and cause the files to not be closed. You may ask then if there was a frame leak before this patch. The answer to that is actually no! The filestream code was "smart" enough to know that since the frame we received came from a format interpreter, the frame had no malloced data and thus didn't need to be freed. Now, however, there is cleanup that needs to be done when we finish with the frame, so we do need to call ast_frfree on the frame to be sure that the refcount for the filestream is decremented appropriately. (closes issue ASTERISK-13495) Reported by: fiddur Patches: 14384.patch uploaded by putnopvut (license 60) Tested by: fiddur, putnopvut ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=173355 By: Digium Subversion (svnbot) 2009-02-04 09:31:26.000-0600 Repository: asterisk Revision: 173356 _U branches/1.6.1/ U branches/1.6.1/main/file.c ------------------------------------------------------------------------ r173356 | mmichelson | 2009-02-04 09:31:26 -0600 (Wed, 04 Feb 2009) | 38 lines Merged revisions 173354 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r173354 | mmichelson | 2009-02-04 09:30:12 -0600 (Wed, 04 Feb 2009) | 30 lines Fix a problem where file playback would cause fds to remain open forever The problem came from the fact that a frame read from a format interpreter was not freed. Adding a call to ast_frfree fixed this. The explanation for why this caused the problem is a bit complex, but here goes: There was a problem in all versions of Asterisk where the embedded frame of a filestream structure was referenced after the filestream was freed. This was fixed by adding reference counting to the filestream structure. The refcount would increase every time that a filestream's frame pointer was pointing to an actual frame of data. When the frame was freed, the refcount would decrease. Once the refcount reached 0, the filestream was freed, and as part of the operation, the open files were closed as well. Thus it becomes more clear why a missing ast_frfree would cause a reference leak and cause the files to not be closed. You may ask then if there was a frame leak before this patch. The answer to that is actually no! The filestream code was "smart" enough to know that since the frame we received came from a format interpreter, the frame had no malloced data and thus didn't need to be freed. Now, however, there is cleanup that needs to be done when we finish with the frame, so we do need to call ast_frfree on the frame to be sure that the refcount for the filestream is decremented appropriately. (closes issue ASTERISK-13495) Reported by: fiddur Patches: 14384.patch uploaded by putnopvut (license 60) Tested by: fiddur, putnopvut ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=173356 |