(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]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
