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
>>
>>
>
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
