[asterisk-dev] Re: Weird errors returned to chan_zap by zaptel

Tony Mountifield tony at softins.clara.co.uk
Thu Nov 9 06:27:32 MST 2006


In article <20061109125825.GG14186 at xorcom.com>,
Tzafrir Cohen <tzafrir.cohen at xorcom.com> wrote:
> On Thu, Nov 09, 2006 at 12:10:05PM +0000, Tony Mountifield wrote:
> > Thanks, looking at /proc/zaptel/1 was the most productive. It showed all
> > the channels as being (In use) except channel 2, on which the problems
> > had been seen. This suggests that fd 14, which had originally been opened
> > on channel 2, had indeed been closed by something, outside of chan_zap.
> 
> Must it be explicitly closed?

It should be left open all the time Asterisk is running. This is true of all
the channel fds.

> > Is it possible from within a function to get a backtrace of where it was
> > called from? I would do this if I determined I was closing an unexpected fd.
> > Or perhaps I just do a crash and use gdb on the core dump. 
> 
> gdb -p ?

I'll have a look at that - thanks.

> > Unfortunately,
> > people are trying to use this system in beta testing (and I need them to,
> > to provoke the error), and they are 8 hours ahead of me in timezone!
> 
> I don't think that there are too many close()-s in chan_zap. Add a
> comment near each. Probably faster.

I've done that already. The fd is not being closed in chan_zap. Something
else is picking up the wrong fd number and calling close when it shouldn't.
That's why I need to trap all the closes in asterisk.

> One other thing: there are far too many places where chan_zap reads (or
> uses an ioctl) and does not check for an error.

Indeed. I've caught many of them as I've been trying to find this, but
there are still some. At least I now display strerror(errno) in every
logged error message, which previously was only done in some places.

At least I have a strategy to work with now. Starting with the following:

#define close(fd) __myclose(__FILE__, __LINE__, __PRETTY_FUNCTION__, #fd, fd)

and so on, inspired by the thread debugging in lock.h

Cheers
Tony
-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org


More information about the asterisk-dev mailing list