Valgrind may complain when software reads out partially uninitialized data
and stores it elsewhere, but only reads the initialized parts from this
latter location. The flag enables code that initializes all the data to
avoid valgrind reporting false positives. Presumably MSAN suffers from
similar issues so, try enabling this flag.
* [ghostscript] Replace deprecated flag by current flag.
In old versions of Ghostscript the flag -dPARANOIDSAFER did
more checks than -dSAFER did. In modern versions the two flags
are identical. Moreover the flag -dPARANOIDSAFER has been
deprecated for a long time, and may be removed in the future.
In Ghostscript 9.50 and later -dSAFER is the default, and does
not have to be specified. To be able to test older yet still
modern Ghostscript versions without problems -dSAFER is used.
* [ghostscript] Force enable banding while rendering.
Ghostscript uses the set resolution to determine if banding should be
enabled during rendering, or not. Under normal circumstances documents
are rendered at maybe 600 DPI, but to conserve memory while running in
OSS-fuzz 200 DPI is used (-r200x200). To still test the banding code
used under normal circumstances banding is force enabled.
Moreover BufferSpace is used to determine the band height and thus the
number of bands. At 600 DPI this is normally 4Mbyte, so a reasonable
approximate at 200 DPI is 450k. Thus BufferSpace is also set.
* [ghostscript] Enable another sanitizer to see more issues.
Apparently the maximum memory usage is 2.5Gbyte so a limit of 3Gbyte
is to liberal. Set limit to 1Gbyte to make sure that any extra memory
used by the fuzzer is allowed. 1Gbyte ought to be enough for most real
world images decoded by jbig2dec.
* grok: add dataflow support
* clean up in Dockerfile
* remove dataflow
Co-authored-by: Max Moroz <balalaikacr3w@gmail.com>
Co-authored-by: Max Moroz <mmoroz@chromium.org>
After many days banging my head on FFI issues in rust,
I hereby present a fix to the issue.
Note that I've got some help, and I'm not sure I understand everything here.
But this is my understanding of what was not working, and how we fixed it.
The **problem** is that on Ubuntu 16 with llvm/clang 10,
we were **statically linking libc++** in [rocksdb][1]:
```rust
let stdlib = if tool.is_like_gnu() {
"libstdc++.a"
} else if tool.is_like_clang() {
"libc++.a"
} else {
// Don't link to c++ statically on windows.
return;
};
// ...
// remove lib prefix and .a postfix.
println!(
"cargo:rustc-link-lib=static={}",
&stdlib[3..stdlib.len() - 2]
);
```
This means that during building, when we reach building of rocksdb,
we import a number of symbols from libc++ (like [__muloti4][2])
that end up in the associated `.rlib` (rust obj file).
These symbols interestingly do not exist in libstdc++ which is used by gcc.
This is important because on linux (unlike mac), the rust toolchain is compiled with gcc.
So these intrinsics are not present in the linux rust toolchain,
and have been redeclared in the [compiler-builtins][3] crate.
So here is the problem:
* rust toolchain's defines these intrinsics functions
* libc++ defines these intrinsics functions
And the recipe for disaster:
* libc++ is statically linked in rocksdb, which means all the symbols are imported
* symbols in rocksdb's produced `.rlib` are colliding with the symbols from the rust toolchain `.rlib`
To fix this. Maybe we could have compiled the stuff with libstdc++?
But instead we:
1. removed the static linking
2. we linked libc++ at the very last moment via:
```rust
RUSTFLAGS="-C link-arg=-L/usr/local/lib -C link-arg=-lc++"
```
At final linking time, the linker sees that the intrinsics are already defined in one of the `.rlib`
(produced by compiler-builtins) and so does not import these functions from libc++.
Actually, at this point it only statically link the functions that need to be linked.
It seems to work.
[1]: c79d2c2ac6/librocksdb_sys/build.rs (L115)
[2]: https://github.com/llvm-mirror/libcxx/blob/master/src/filesystem/int128_builtins.cpp
[3]: e578d47247/src/int/mul.rs (L107)
* Added xpdf project.
* Tried linking with cxx.
* Since the executables build are not needed for the fuzzer build to succeed we can ignore the case where some test-apps are not build on the oss-fuzz platform.
* Ignore errors that dont impact the fuzzers.
* Updated the project file with language field.
[bignum-fuzzer] Mbed TLS no longer has an mbed-crypto submodule
Mbed TLS has gone back to being self-contained, without a separate
submodule for the cryptography part of the library. Revert the
bignum-fuzzer build scripts accordingly.
This reverts commit 54733ddc84.
Teju Nareddy