Nice catch Chris, I will patch that up over the weekend. Piotr
On 29 May 2014 10:19, Christopher Horvath <[email protected]> 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 <[email protected]> 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" <[email protected]> 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" < >> [email protected]> >> >>> 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 >> >>> [email protected] >> >>> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> >> _______________________________________________ >> >> Openexr-devel mailing list >> >> [email protected] >> >> https://lists.nongnu.org/mailman/listinfo/openexr-devel >> > >> > >> > _______________________________________________ >> > Openexr-devel mailing list >> > [email protected] >> > 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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/openexr-devel > >
_______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel
