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

[Tony Mountifield]

In article <e0a13b711eed7016ff887c524e4db5eb at digium.com>,
Matthew Fredrickson <creslin at digium.com> wrote:
> 
> On Nov 9, 2006, at 8:51 AM, Tzafrir Cohen wrote:
> 
> > On Thu, Nov 09, 2006 at 01:27:32PM +0000, Tony Mountifield wrote:
> >> 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:
> >
> >>>> 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.
> >
> > libpri seems to do some file operations of its own, right?
> 
> Reads and write, but not opens and closes.  That's all done by the 
> application using libpri.

For anyone who was following this thread and wondered about the outcome,
I finally tracked down where the spurious close was coming from.

It was in a custom feature I had added to meetme, that was only getting
invoked occasionally by the users. In this feature I had the following
snippet of code within conf_run():

     close(fd);
     goto outrun;

In fact that should have been:

     if (using_pseudo) close(fd);
     goto outrun;

So the bug never appeared on my test system which was using SIP phones,
when fd refers to a pseudo-channel that does indeed need to be closed,
but only on the production system using Zap channels, where fd refers
to the actual channel, and must be left open!

There are in fact a lot of error exits from conf_run() when ioctl()
returns an error, that call close(fd) unconditionally, and should
make the call conditional on (using_pseudo). Of course, they don't
get executed during normal operation.

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