In article <[EMAIL PROTECTED]>,
Matthew Fredrickson <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>,
> >> Tzafrir Cohen <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] - http://www.softins.co.uk
Play: [EMAIL PROTECTED] - http://tony.mountifield.org
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to