I can't answer... nor do I think I would be allowed to if I knew the
answer! Which I don't!
On Thu, May 29, 2014 at 10:22 AM, Piotr Stanczyk
<piotr.stanc...@gmail.com>wrote:
> btw - I'd be curious to know for the need of such env. From a practical
> p.o.v.
>
> Piotr
>
>
> On 29 May 2014 10:21, Piotr Stanczyk <piotr.stanc...@gmail.com> wrote:
>
>> Nice catch Chris, I will patch that up over the weekend.
>>
>> Piotr
>>
>>
>> On 29 May 2014 10:19, Christopher Horvath <blackenc...@gmail.com> wrote:
>>
>>> I'm in a crippled environment that explicitly disallows exceptions, and
>>> has modified underlying some (but not all) underlying libraries
>>> accordingly. I worked a bit to try to incorporate these restrictions into
>>> the fuzz tests, but ultimately gave up - I'm trusting that the fuzz tests
>>> will have been run elsewhere.
>>>
>>> Additionally, there's a bug in one of the main tests. In
>>> testMultiPartSharedAttributes.cpp, in the testHeaders function, the first
>>> call is to:
>>>
>>> vector<Header> headers;
>>> // expect this to fail - empty header list
>>> testMultiPartOutputFileForExpectedFailure (headers,
>>> fn,
>>> "Header : empty header
>>> list passed");
>>>
>>> And then inside the testMultiPartOutputFileForExpectedFailure function,
>>> the code takes the address of the 0'th element of the vector, which is
>>> invalid for an empty vector, and throws an exception which is not caught:
>>>
>>> try
>>> {
>>> remove(fn.c_str());
>>> MultiPartOutputFile file(fn.c_str(), &headers[0],headers.size());
>>> cerr << "ERROR -- " << failMessage << endl;
>>> assert (false);
>>> }
>>> catch (const IEX_NAMESPACE::ArgExc & e)
>>> {
>>> // expected behaviour
>>> }
>>>
>>> The &headers[0] is invalid on an empty list, and causes a test failure.
>>>
>>> I've just disabled this test locally - all other non-tests succeed.
>>>
>>>
>>>
>>> On Thu, May 29, 2014 at 10:06 AM, Chris Cox <c...@adobe.com> wrote:
>>>
>>>>
>>>> That could be because "new" is defined in the language as throwing an
>>>> exception if it fails to allocate memory. Doing a NULL check after
>>>> "new"
>>>> would only be necessary if running in a crippled environment that does
>>>> not
>>>> support exceptions.
>>>>
>>>> Malloc/calloc/realloc should never throw, but return NULL if they fail
>>>> to
>>>> allocate memory.
>>>>
>>>>
>>>> Chris
>>>>
>>>>
>>>> On 5/28/14 11:57 PM, "Peter Hillman" <pet...@wetafx.co.nz> wrote:
>>>>
>>>> >
>>>> > The OpenEXR fuzz tests insert bytes into files to test what happens
>>>> with
>>>> > accidentally or maliciously damaged files.
>>>> > When a "length-of-attribute" field in the EXR Header is modified to be
>>>> > an extremely large number, the library will often attempt to allocate
>>>> a
>>>> > large amount of memory to load the supposedly large attribute. There's
>>>> > no standard place where this happens; each attribute type manages
>>>> > loading the values itself. The field storing type of the attribute may
>>>> > also become damaged, causing unusual behaviour.
>>>> >
>>>> > It seems like the OpenEXR library does rather assume that calls to
>>>> 'new'
>>>> > etc will throw exceptions if they fail, rather than nullptr testing.
>>>> > This is in the library itself, rather than the fuzz tests.
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On 29/05/14 13:26, Nick wrote:
>>>> >> Are you saying you have a malloc implementation that crashes if it
>>>> can't
>>>> >> allocate due to not enough memory? Or are you saying that the fuzz
>>>> test
>>>> >> relies on an exception not a nullptr test? If the latter it would be
>>>> better
>>>> >> to modify the test to null test. If the former, what the heck?
>>>> >>
>>>> >> Fuzz tests generally are supposed to demonstrate that the library
>>>> can survive
>>>> >> malicious exploits like forced overruns or whatever through
>>>> malformed files.
>>>> >>
>>>> >> If you are crashing, it's a bad malloc, a bad test, or OpenEXR isn't
>>>> >> completely fuzz safe.
>>>> >>
>>>> >> Or this is a different use of the term fuzz testing that I am not
>>>> familiar
>>>> >> with ;)
>>>> >>
>>>> >> - Nick
>>>> >>
>>>> >> Sent from my iPhone
>>>> >>
>>>> >>> On May 28, 2014, at 15:01, "Christopher Horvath" <
>>>> blackenc...@gmail.com>
>>>> >>> wrote:
>>>> >>>
>>>> >>> Hey Folks,
>>>> >>>
>>>> >>> It seems like some of the fuzz tests are explicitly attempting to
>>>> fail by
>>>> >>> creating large allocations and catching exceptions from failed
>>>> memory
>>>> >>> allocations. If you're working with a malloc library that has
>>>> exceptions
>>>> >>> turned off, this causes crashes...
>>>> >>>
>>>> >>> Is this the correct interpretation of how fuzzScanLines & fuzzFile
>>>> is
>>>> >>> intended to work?
>>>> >>>
>>>> >>> This seems to be testing that malloc throws correctly - which in my
>>>> case, it
>>>> >>> does not - I just want to make sure I can feel comfortable turning
>>>> these
>>>> >>> fuzz tests off for the future.
>>>> >>>
>>>> >>> Chris
>>>> >>>
>>>> >>> --
>>>> >>> I think this situation absolutely requires that a really futile and
>>>> stupid
>>>> >>> gesture be done on somebody's part. And we're just the guys to do
>>>> it.
>>>> >>> _______________________________________________
>>>> >>> Openexr-devel mailing list
>>>> >>> Openexr-devel@nongnu.org
>>>> >>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>> >> _______________________________________________
>>>> >> Openexr-devel mailing list
>>>> >> Openexr-devel@nongnu.org
>>>> >> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Openexr-devel mailing list
>>>> > Openexr-devel@nongnu.org
>>>> > https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>>
>>>>
>>>
>>>
>>> --
>>> I think this situation absolutely requires that a really futile and
>>> stupid gesture be done on somebody's part. And we're just the guys to do
>>> it.
>>>
>>> _______________________________________________
>>> Openexr-devel mailing list
>>> Openexr-devel@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>
>>>
>>
>
--
I think this situation absolutely requires that a really futile and stupid
gesture be done on somebody's part. And we're just the guys to do it.
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
