Closed lpereira closed 5 years ago
Looking.
Hm, I'm able to reproduce it locally:
$ python infra/helper.py pull_images
$ python infra/helper.py build_image --no-pull lwan
$ python infra/helper.py build_fuzzers lwan
<...>
[6/48] : && /usr/local/bin/clang -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -fno-plt -Wdouble-promotion -Wno-unused-parameter -Wvla -Wall -Wextra -Wshadow -Wconversion -std=gnu99 -g -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack src/bin/tools/CMakeFiles/bin2hex.dir/bin2hex.c.o -o src/bin/tools/bin2hex -rdynamic && :
/src/lwan/src/lib/hash.c:284:15: warning: implicit declaration of function 'reallocarray' is invalid in C99 [-Wimplicit-function-declaration]
tmp = reallocarray(bucket->entries, new_total, sizeof(*tmp));
^
/src/lwan/src/lib/hash.c:284:13: warning: incompatible integer to pointer conversion assigning to 'struct hash_entry *' from 'int' [-Wint-conversion]
tmp = reallocarray(bucket->entries, new_total, sizeof(*tmp));
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/src/lwan/src/lib/hash.c:480:38: warning: implicit declaration of function 'reallocarray' is invalid in C99 [-Wimplicit-function-declaration]
struct hash_entry *tmp = reallocarray(
^
/src/lwan/src/lib/hash.c:480:32: warning: incompatible integer to pointer conversion initializing 'struct hash_entry *' with an expression of type 'int' [-Wint-conversion]
struct hash_entry *tmp = reallocarray(
^ ~~~~~~~~~~~~~
4 warnings generated.
[7/48] : && /usr/local/bin/clang -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -fno-plt -Wdouble-promotion -Wno-unused-parameter -Wvla -Wall -Wextra -Wshadow -Wconversion -std=gnu99 -g -Wl,-z,now -Wl,-z,relro -Wl,-z,noexecstack src/bin/tools/CMakeFiles/mimegen.dir/mimegen.c.o src/bin/tools/CMakeFiles/mimegen.dir/__/__/lib/hash.c.o src/bin/tools/CMakeFiles/mimegen.dir/__/__/lib/murmur3.c.o src/bin/tools/CMakeFiles/mimegen.dir/__/__/lib/missing.c.o -o src/bin/tools/mimegen -rdynamic -lz && :
[8/48] cd /work/lwan/src/lib && /work/lwan/src/bin/tools/bin2hex /src/lwan/wwwroot/icons/back.gif back_gif /src/lwan/wwwroot/icons/file.gif file_gif /src/lwan/wwwroot/icons/folder.gif folder_gif > /work/lwan/auto-index-icons.h
[9/48] cd /work/lwan/src/lib && /work/lwan/src/bin/tools/mimegen /src/lwan/src/bin/tools/mime.types > /work/lwan/mime-types.h
FAILED: cd /work/lwan/src/lib && /work/lwan/src/bin/tools/mimegen /src/lwan/src/bin/tools/mime.types > /work/lwan/mime-types.h
AddressSanitizer:DEADLYSIGNAL
=================================================================
==519==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000030 (pc 0x0000004c4aed bp 0x7fff8ef73420 sp 0x7fff8ef733c0 T0)
==519==The signal is caused by a WRITE memory access.
==519==Hint: address points to the zero page.
#0 0x4c4aec in hash_add_entry_hashed /src/lwan/src/lib/hash.c:304:20
#1 0x4c3a65 in hash_add_unique /src/lwan/src/lib/hash.c:403:32
#2 0x4c186e in main /src/lwan/src/bin/tools/mimegen.c:204:17
#3 0x7f73a009382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#4 0x41b468 in _start (/work/lwan/src/bin/tools/mimegen+0x41b468)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /src/lwan/src/lib/hash.c:304:20 in hash_add_entry_hashed
==519==ABORTING
ninja: build stopped: subcommand failed.
Fuzzers build failed.
Thanks for taking a look, @Dor1s.
Wondering what's different, then. Here's the asciinema recording of the same commands being executed on my machine. (Prior to recording the session, pull_image
actually updated the images.)
I've updated the container to a new Ubuntu version (bionic
, the next LTS), and the problem persists.
unbound
had issues related to reallocarray recently (#2393), but it looks unrelated.
Thanks for the recording, @lpereira. Weird...
Hm, I've noticed some different in the compilation flags:
OSS-Fuzz:
/usr/local/bin/clang -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -I/src/lwan/src/lib/missing -I/src/lwan/src/lib -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -fno-plt -Wdouble-promotion -Wno-unused-parameter -Wvla -Wall -Wextra -Wshadow -Wconversion -std=gnu99 -g -include /work/lwan/lwan-build-config.h -MMD -MT src/bin/tools/CMakeFiles/mimegen.dir/__/__/lib/hash.c.o -MF src/bin/tools/CMakeFiles/mimegen.dir/__/__/lib/hash.c.o.d -o src/bin/tools/CMakeFiles/mimegen.dir/__/__/lib/hash.c.o -c /src/lwan/src/lib/hash.c
Your recording:
/usr/local/bin/clang -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -I/src/lwan/src/lib/missing -I/src/lwan/src/lib -I. -O1 -fno-omit-frame-pointer -gline-tables-only -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -fno-plt -Wdouble-promotion -Wno-unused-parameter -Wvla -Wall -Wextra -Wshadow -Wconversion -std=gnu99 -g -fsanitize=address -include /work/lwan/lwan-build-config.h -fPIC -MMD -MT src/lib/CMakeFiles/lwan-static.dir/hash.c.o -MF src/lib/CMakeFiles/lwan-static.dir/hash.c.o.d -o src/lib/CMakeFiles/lwan-static.dir/hash.c.o -c /src/lwan/src/lib/hash.c
Extra flags in your recording:
-fsanitize=address
- shouldn't matter, as it's used for the second time, though might cause some issues in non-ASan build (not the case right now)-fPIC
- suspicious, where does it come from? Are you running oss-fuzz checkout on master branch, or have some local changes?Hah. That was it: master
was a few days old (HEAD
was at 7ec14aed). I've just reproduced the issue locally.
I'm closing the issue, thank you!
Issue 14646 has been filled against Lwan. I can't reproduce it locally (using the container with the infra helper script).
It seems that
reallocarray()
is detected during the cmake configuration phase, but the prototype is not defined whenhash.c
is being compiled. It should be, both_DEFAULT_SOURCE
and_GNU_SOURCE
are defined before all headers are included; this should be sufficient for glibc to define its prototype. I don't know if that's the issue, but since the return value is implicitlyint
in this case (rather thanvoid *
), and it's segfaulting when trying to use its value...However, I can't get this warning or reproduce the failure in any way. I've updated the base image, rebuilt everything from the scratch, tried building in a similar system (without a container) with the same build flags, etc.
Is there something I'm missing here?