Commit Graph

8 Commits

Author SHA1 Message Date
jonathanmetzman ec331c1c6a
Try again to unbreak librawspeed by actually using gold (#2786) 2019-08-30 17:34:51 -07:00
jonathanmetzman 824f9f3928
Fix librawspeed build (#2784) 2019-08-30 11:29:20 -07:00
Roman Lebedev 960cc7d793 [librawspeed] LIB_FUZZING_ENGINE fixes (#2317) (#2377)
* [librawspeed] LIB_FUZZING_ENGINE fixes

Depends on 8906ca4a40
Refs. https://github.com/google/oss-fuzz/issues/2317

* [librawspeed] Drop dead CMake WITH_PTHREADS param

It is gone from RawSpeed's CMake, there is no longer any direct
dependecy on PThreads.
2019-05-03 11:28:58 -07:00
jonathanmetzman ae9398deef
Change LIB_FUZZING_ENGINE to -fsanitize=fuzzer in libFuzzer builds (#2312) 2019-04-15 10:05:02 -07:00
Roman Lebedev dec4d4272f [librawspeed] Undefined Sanitizer: enable unsigned-integer-overflow detection. (#1011)
As discussed in https://github.com/google/oss-fuzz/issues/682#issuecomment-347236010
2017-11-27 11:23:07 -08:00
Roman Lebedev 430a173d1a RawSpeed: fix build. (#997)
During introduction of more fuzz targets, i did some CMake cleanup,
namely adding of helper library. And unfortunately i did not think
about the LIB_FUZZING_ENGINE env variable, thus the oss-fuzz build
has failed.

So some more cleanup was needed
(darktable-org/rawspeed@986d605935),
and as the consequences, this small build.sh change is needed too.

I did check locally, this does fix the build.
Please merge :)
2017-11-18 07:21:59 -08:00
Roman Lebedev 808a1ba671 RawSpeed project change (#752)
Specify one cmake option, in hope that it might magically fix strange Ill crashes, which are not reproducible locally.
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=2816
2017-07-31 16:56:23 -07:00
Roman Lebedev af03d10626 RawSpeed: finish integration by adding fuzzing targets. (#685)
As discussed in the original PR#588, it may be better to
start with empty corpus, and see what happens. Even though
i have the full corpus set to get full (80%+) coverage, it
is quite likely to result in horrible performance.

Currently, the library is built with no external
dependencies - jpeg, zlib - not too sure if it makes sense
to fuzz those indirectly. And if i can built zlib in-tree,
building jpeg in-tree will be more complicated because it
does not have CMake build system.

As you can see, more than one fuzzing target is provided.
The RawSpeedFuzzer is the most global one, it will be
able to eventually cover all the code, others are more
fine-grained, and will only be able to cover some small
portion of the code. Thus, i suppose both the performance
and the coverage may win.

I did test this locally. Both the address and the undefined
configurations work.
2017-06-21 11:43:36 -07:00