Yeah, we use many thousands of textures at a time with no problem. I'm going to bet that you'll only get this failure because you use "*.tex" as the extension, which leads it to not guessing which kind of file it is, and therefore trying each plugin in turn.
I have some ideas about how to fix, will try to take a look at it tonight. On Jun 11, 2012, at 5:23 PM, Stephen Parker wrote: > (b) Fails same as 1.0 unless socket plug-in is removed (with error -> "epoll: > Too many open files") > > The only thing specific to this asset I think is the number and file type of > the textures. > The render utilizes 1287 unique textures which are 8-bit sRGB mip-mapped > tiffs with a *.tex extension. > > It's a little strange because we've handled significantly more textures than > this in the past. > > I'm linking against boost 1.43. Everything was compiled with gcc 4.1 and runs > on CentOS 5. > Our ulimit is 4096. > > -steve > > > From: Larry Gritz <[email protected]> > To: Stephen Parker <[email protected]> > Cc: OpenImageIO developers <[email protected]> > Sent: Monday, June 11, 2012 4:19 PM > Subject: Re: [Oiio-dev] epoll: too many files open ?? > > 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] > > > > -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
