[asterisk-dev] streamfile reference counting debug
Paul Albrecht
albrecht at glccom.com
Mon Apr 20 15:31:31 CDT 2009
On Mon, 2009-04-20 at 15:26 -0500, Mark Michelson wrote:
> Paul Albrecht wrote:
> > Hi,
> >
> > I'm maintaining an asterisk module, a hacked appconference, which I've
> > migrated to asterisk 1.6. Since I've updated the module, I've noticed
> > the conference application fails after running for some time because it
> > has reached the process limit for open file descriptors. It appears that
> > the module burns a file descriptor whenever a sound is played to a
> > conference member.
>
> This sounds remarkably similar to a bug that has been fixed already:
>
> The bug:
> http://bugs.digium.com/view.php?id=14384
>
> The fix was made in revision 173354 of Asterisk trunk, and was merged in
> subsequent revisions to all 1.6 branches.
>
> What branch of 1.6 are you using? Is your checkout older than 4 Feb from this
> year? If so, it should be updated so that it contains the changes made for the
> issue I linked to above.
>
I think I have that fix ... here's the output for 'asterisk -rx "core show version"'
Asterisk SVN-trunk-r186687M built by root @ testbridge16 on a x86_64 running Linux on 2009-04-20 16:11:57 UTC
> >
> > Specifically, when the module plays a sound to a conference member, it
> > opens the sound file, processes the file for that member, and then
> > closes the file. I can see the file is still open after the module
> > finishes playing the sound and closes the file by listing open file
> > descriptors with this command: "lsof -c asterisk." I also see that the
> > object count is incremented by one when I do "astobj2 show stats" at the
> > asterisk command line.
> >
> > How can I debug this problem?
> >
>
> Debugging refcount issues is a bit tricky, especially when it comes to debugging
> a reference leak. I suggest reading the section in astobj2.h titled "DEBUGGING
> REF COUNTS BIBLE." Note that if you are using Asterisk 1.6.0, then this section
> is not included and the reference count debugging is not present either.
>
> Mark Michelson
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Paul Albrecht
More information about the asterisk-dev
mailing list