LIU Yuwei

Maybe try tool/gen_library_abilist.sh to ignore the whole lib as described in example.md？

I'm still wondering whether they use LLVM 7 or LLVM 6, since the declaration in https://github.com/HexHive/FuzzGen/blob/34411151d58cd9414c1ede4874716c64789efd16/src/preprocessor/preprocessor.h#L210-L212 matches with https://github.com/llvm/llvm-project/blob/release/7.x/clang/include/clang/Lex/PPCallbacks.h#L124-L134 ``` virtual void InclusionDirective(SourceLocation HashLoc, const Token &IncludeTok, StringRef FileName, bool...

成功部署；Digital Ocean；Linux 16.04

I cannot reproduce the crash with the provided [poc](https://github.com/dandanxu96/PoC/blob/main/ffjpeg/ffjpeg-bmp_load-integer-overflow) file. ``` ❯ ./bin_asan/bin/ffjpeg -e ffjpeg-bmp_load-integer-overflow ================================================================= ==2742398==ERROR: AddressSanitizer: allocator is out of memory trying to allocate 0x1555555c00 bytes #0 0x4c5587...

The poc file is downloaded from the browser, but the `xxd` shows same result as yours: ``` ❯ xxd ffjpeg-bmp_load-integer-overflow 00000000: 5f55 5555 5555 553d 3635 7155 5555 5455 _UUUUUU=65qUUUTU...

OK, I get it. This is caused by the different size of `unsigned long`. In 64-bit program, `unsigned long` is 8 bytes while in 32-bit `unsigned long` is 4 bytes....

I cannot reproduce the crash with the provided poc, neither in normally compiled ffjpeg or ffjpeg compiled with Address Sanitizer. With the provided poc, the size in `fread()` is -3....

The details about the downloaded poc file: ``` ❯ xxd ffjpeg-jfif_load-buffer-overflow 00000000: 9090 9090 90b3 9090 90a3 908a f5ec f4f4 ................ 00000010: 0000 2100 20ff e8 ..!. .. ❯ sha1sum...

With program compiled with afl-gcc, I can get the following crash report: ``` Breakpoint 4, jfif_load (file=) at jfif.c:171 171 size |= fgetc(fp)

So it is a bug caused by afl-gcc instead of a bug of ffjpeg, right? Since fread is not expected to crash when the size is very large.