Just to clarify: (a) master branch WORKS as-is?
(b) master branch FAILS the same as 1.0 did, until you disable the socket plugin? If it's (b), can you try to give me a clear recipe to reproduce the problem? On Jun 11, 2012, at 3:54 PM, Stephen Parker wrote: > Using the master branch, the same error appears WITHOUT disabling the socket > plug-in. > > > > From: Larry Gritz <[email protected]> > To: Stephen Parker <[email protected]> > Cc: OpenImageIO developers <[email protected]> > Sent: Friday, June 8, 2012 5:51 PM > Subject: Re: [Oiio-dev] epoll: too many files open ?? > > Yeah, is it possible for you to compile the OIIO master branch and see if > (WITHOUT removing socket.imageio), it also fixes the problem? > > If that's ok, I'll backport some kind of fix to the plugin search logic to > the 1.0 branch. > > > > On Jun 8, 2012, at 5:48 PM, Stephen Parker wrote: > >> Sorry it took so long ... had to wait for renders. Removing the socket >> plug-in from the build has fixed the errors. >> Is there anything else you'd like me to test or information you'd like me to >> provide regarding versions of >> dependent libraries, etc? >> >> As usual, thanks for replying so quickly. >> >> -s >> >> From: Larry Gritz <[email protected]> >> To: Stephen Parker <[email protected]> >> Cc: OpenImageIO developers <[email protected]> >> Sent: Friday, June 8, 2012 1:41 PM >> Subject: Re: [Oiio-dev] epoll: too many files open ?? >> >> What I'm worried about is that it's trying every plugin on your file, and >> thus coincidentally doing a lot of open() calls with the socket plugin even >> though it's not needed, and maybe the socket plugin is leaking something >> inadvertently. >> >> I'd also be curious if it's a problem for you in the master branch. We >> recently overhauled the algorithm for plugin selection (being more careful >> about trying the right plugin first, the one implied by the file extension, >> and only as a last resort going through the whole list of plugins), and I >> don't think that was backported to 1.0 since nobody had specifically >> complained about it. >> >> -- lg >> >> >> On Jun 8, 2012, at 12:13 PM, Stephen Parker wrote: >> >>> This is in 1.0.4. I was actually in the process of removing the socket >>> plug-in when I wrote the list. I'll follow-up shortly. We just discovered >>> it this morning when looking through some logs. >>> >>> From: Larry Gritz <[email protected]> >>> To: Stephen Parker <[email protected]>; OpenImageIO developers >>> <[email protected]> >>> Sent: Friday, June 8, 2012 11:55 AM >>> Subject: Re: [Oiio-dev] epoll: too many files open ?? >>> >>> Which branch? >>> >>> Just out of curiosity, what if you alter the src/CMakeLists.txt and >>> src/libOpenImageIO/CMakeLists.txt to remove the references to >>> socket.imageio, does that make the problem go away? >>> >>> >>> >>> On Jun 8, 2012, at 11:52 AM, Stephen Parker wrote: >>> >>>> Hey, >>>> >>>> A year or so ago we had some issues with file handles not being closed >>>> which Larry promptly addressed and we haven't seen the problem again until >>>> recently. This time however, the error message is a bit different - >>>> involving epoll. From what I've gathered the only place this would be >>>> called is through boost.asio and only as it pertains to iv and sockets. I >>>> haven't really dug into it too far, but wanted to hit the list and see if >>>> anyone could offer up a guess as to why we'd see this type of error when >>>> using the texture cache. We're catching this exception inside a very thin >>>> wrapper around openimageio at render time. This can be difficult to >>>> troubleshoot unless you've got several thousand unique textures at your >>>> disposal (which is the case for us). I'll continue to investigate but just >>>> thought I'd ask for an educated guess first. I've set the maxfiles for the >>>> texture cache to half of what our ulimit is - but the problem persists. >>>> I'm using boost 1.43, btw. >>>> >>>> I'm not expecting a solution with what little information I've provided, >>>> but I'll follow-up with more info and see if it warrants a bug report. >>>> >>>> -steve >>>> ___ > > > > -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
