Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Problems building zlibvc using Visual C++ Express 2010 #1

Closed
lekanteto opened this issue Feb 5, 2012 · 2 comments
Closed

Problems building zlibvc using Visual C++ Express 2010 #1

lekanteto opened this issue Feb 5, 2012 · 2 comments

Comments

@lekanteto
Copy link

------ Erstellen gestartet: Projekt: zlibvc, Konfiguration: Release Win32 ------
gzlib.c
......\gzlib.c(180): warning C4013: 'open' undefiniert; Annahme: extern mit Rückgabetyp int
......\gzlib.c(204): warning C4013: '_lseeki64' undefiniert; Annahme: extern mit Rückgabetyp int

This can be solved by changing in gzlib.c

#  define LSEEK _lseeki64

to

#  define LSEEK _lseeki64
#  include <io.h>
@madler
Copy link
Owner

madler commented Feb 5, 2012

This should be fixed by one of the commits already on the develop branch, which added an #include <io.h> when _MSC_VER is defined. Please try the develop branch and let me know if that fixes it. Thanks.

@lekanteto
Copy link
Author

Development branch fixed the issue. Sorry for not checking it before opening this issue

smuzaffar pushed a commit to cms-externals/zlib that referenced this issue Feb 6, 2017
@vkrasnov
Merge pull request madler#1 from cloudflare/match.four
93f5fe1 
It changes the hash and longest match functions to always match at least 4 bytes, instead the 3 the spec allows. It allows for faster and more effective compression because there are less hash collisions, and false matches are discarded faster.
In theory it could lead to worse compression in some cases, but for the most common files there is an improvement for all levels both in speed and in compression ratio.
@Adenilson Adenilson mentioned this issue Apr 25, 2017
Closed
sebpop pushed a commit to sebpop/zlib that referenced this issue Nov 15, 2018
oss-fuzz/11360: clear out s->prev buffer to avoid undefined behavior
d07add4 
this patch fixes a use of uninitialized value discovered by one of the fuzzers
of the oss-fuzz project:
https://github.com/google/oss-fuzz/blob/master/projects/zlib/example_dict_fuzzer.c
clang's memory sanitizer fails with:

==1==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x5930dd in slide_hash zlib/deflate.c:222:20
    madler#1 0x589461 in fill_window zlib/deflate.c:1558:13
    madler#2 0x59828f in deflate_rle zlib/deflate.c:2119:13
    madler#3 0x590614 in deflate zlib/deflate.c:1045:41
    madler#4 0x4a2d56 in test_dict_deflate /src/example_dict_fuzzer.c:79:11
    madler#5 0x4a3e9b in LLVMFuzzerTestOneInput /src/example_dict_fuzzer.c:156:3
    madler#6 0x4ed04b in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
    madler#7 0x4a4ff6 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
    madler#8 0x4b5e1a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:713:9
    madler#9 0x4a4121 in main /src/libfuzzer/FuzzerMain.cpp:20:10
    madler#10 0x7f3d7a13b82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
    madler#11 0x41ed08 in _start
  Uninitialized value was created by a heap allocation
    #0 0x45fa10 in malloc /src/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:911
    madler#1 0x586920 in deflateInit2_ zlib/deflate.c:320:27
    madler#2 0x4a2a24 in test_dict_deflate /src/example_dict_fuzzer.c:61:11
    madler#3 0x4a3e9b in LLVMFuzzerTestOneInput /src/example_dict_fuzzer.c:156:3
    madler#4 0x4ed04b in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
    madler#5 0x4a4ff6 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
    madler#6 0x4b5e1a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:713:9
    madler#7 0x4a4121 in main /src/libfuzzer/FuzzerMain.cpp:20:10
    madler#8 0x7f3d7a13b82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
@sebpop sebpop mentioned this issue Nov 15, 2018
Closed
hzhuang1 pushed a commit to Linaro/warpdrive-zlib that referenced this issue Jul 31, 2019
@Dead2
fix madler#197, oss-fuzz/10036: only write 4 bytes per iteration in d…
11989c9 
…eflate_quick

by aggregating the two consecutive values to be written by static_emit_ptr to
s->pending_buf and writing the two values at once in a 4 byte store, we avoid
running out of the allocated buffer. We used to call quick_send_bits twice and
bumped the counter s->pending in the first call, which made the second call
write to memory beyond the safe 4 bytes that were guaranteed by the following
condition in the enclosing loop in deflate_quick:

  if (s->pending + 4 >= s->pending_buf_size) {
    flush_pending(s->strm);

The bug was exposed by the memory sanitizer like so:

MemorySanitizer:DEADLYSIGNAL
--
  | ==1==ERROR: MemorySanitizer: SEGV on unknown address 0x730000020000 (pc 0x0000005b6ce4 bp 0x7fff59adb5e0 sp 0x7fff59adb570 T1)
  | ==1==The signal is caused by a WRITE memory access.
  | #0 0x5b6ce3 in quick_send_bits zlib-ng/arch/x86/deflate_quick.c:134:48
  | madler#1 0x5b5752 in deflate_quick zlib-ng/arch/x86/deflate_quick.c:243:21
  | madler#2 0x590a15 in zng_deflate zlib-ng/deflate.c:952:18
  | madler#3 0x587165 in zng_compress2 zlib-ng/compress.c:59:15
  | madler#4 0x5866d3 in check_compress_level zlib-ng/test/fuzz/compress_fuzzer.c:22:3
  | madler#5 0x5862d8 in LLVMFuzzerTestOneInput zlib-ng/test/fuzz/compress_fuzzer.c:74:3
  | madler#6 0x4e9b48 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:575:15
  | madler#7 0x4a2f66 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
  | madler#8 0x4b3adb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9
  | madler#9 0x4a2091 in main /src/libfuzzer/FuzzerMain.cpp:20:10
  | madler#10 0x7fb8919b082f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
  | madler#11 0x41ec68 in _start
  | MemorySanitizer can not provide additional info.
  | SUMMARY: MemorySanitizer: SEGV (/mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds_zlib-ng_7ead0a3e4980f024583384fd355b6e3ddd4b2ca2/revisions/compress_fuzzer+0x5b6ce3)
hzhuang1 pushed a commit to Linaro/warpdrive-zlib that referenced this issue Jul 31, 2019
@Dead2
fix bugs madler#186 and madler#191, oss-fuzz/9831: use-of-uninitializ…
cf1e67e 
…ed-value

==1==WARNING: MemorySanitizer: use-of-uninitialized-value
  #0 0x59fa93 in deflate_medium zlib-ng/deflate_medium.c:259:21
  madler#1 0x590905 in zng_deflate zlib-ng/deflate.c:951:18
  madler#2 0x587095 in zng_compress2 zlib-ng/compress.c:59:15
  madler#3 0x5866e3 in check_compress_level zlib-ng/test/fuzz/compress_fuzzer.c:18:3
  madler#4 0x5862fd in LLVMFuzzerTestOneInput zlib-ng/test/fuzz/compress_fuzzer.c:38:3
  madler#5 0x4e9b48 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:575:15
  madler#6 0x4a2f66 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
  madler#7 0x4b3adb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9
  madler#8 0x4a2091 in main /src/libfuzzer/FuzzerMain.cpp:20:10
  madler#9 0x7fea2fea482f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
  madler#10 0x41ec68 in _start
Uninitialized value was created by a heap allocation
  #0 0x45f2a0 in malloc /src/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:910
  madler#1 0x587d42 in zng_deflateInit2_ zlib-ng/deflate.c:284:27
  madler#2 0x5874fa in zng_deflateInit_ zlib-ng/deflate.c:224:12
  madler#3 0x586c95 in zng_compress2 zlib-ng/compress.c:41:11
  madler#4 0x5866e3 in check_compress_level zlib-ng/test/fuzz/compress_fuzzer.c:18:3
  madler#5 0x5862fd in LLVMFuzzerTestOneInput zlib-ng/test/fuzz/compress_fuzzer.c:38:3
  madler#6 0x4e9b48 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:575:15
  madler#7 0x4a2f66 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
  madler#8 0x4b3adb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9
  madler#9 0x4a2091 in main /src/libfuzzer/FuzzerMain.cpp:20:10
  madler#10 0x7fea2fea482f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
hzhuang1 pushed a commit to Linaro/warpdrive-zlib that referenced this issue Jul 31, 2019
@Dead2
fix bug madler#192, oss-fuzz/9827 : MemorySanitizer:DEADLYSIGNAL
29b6ab4 
==4908==ERROR: MemorySanitizer: SEGV on unknown address 0x730fffffffff (pc 0x0000004b1b97 bp 0x7ffd4bf59a00 sp 0x7ffd4bf598a0 T4908)
==4908==The signal is caused by a READ memory access.
  #0 0x5a0599 in fizzle_matches zlib-ng/deflate_medium.c:168:12
  madler#1 0x59ea27 in deflate_medium zlib-ng/deflate_medium.c:296:21
  madler#2 0x5901c5 in zng_deflate zlib-ng/deflate.c:951:18
  madler#3 0x586955 in zng_compress2 zlib-ng/compress.c:59:15
  madler#4 0x5861eb in LLVMFuzzerTestOneInput zlib-ng/test/fuzz/compress_fuzzer.c:18:3
  madler#5 0x4e9b48 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:575:15
  madler#6 0x4a2f66 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
  madler#7 0x4b3adb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9
  madler#8 0x4a2091 in main /src/libfuzzer/FuzzerMain.cpp:20:10
  madler#9 0x7fa3d7ff582f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
  madler#10 0x41ec68 in _start
hzhuang1 pushed a commit to Linaro/warpdrive-zlib that referenced this issue Jul 31, 2019
@Dead2
fix ASAN crash on test/minigzip
5bb573f 
Before this patch, when configuring with address sanitizer:

./configure --with-sanitizers
make
make test

used to fail with the following error:

$ echo hello world | ./minigzip
ASAN:SIGSEGV
=================================================================
==17466==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000fc80 (pc 0x7fcacddd46f8 bp 0x7ffd01ceb310 sp 0x7ffd01ceb290 T0)
    #0 0x7fcacddd46f7 in _IO_fwrite (/lib/x86_64-linux-gnu/libc.so.6+0x6e6f7)
    madler#1 0x402602 in zng_gzwrite /home/spop/s/zlib-ng/test/minigzip.c:180
    madler#2 0x403445 in gz_compress /home/spop/s/zlib-ng/test/minigzip.c:305
    madler#3 0x404724 in main /home/spop/s/zlib-ng/test/minigzip.c:509
    madler#4 0x7fcacdd8682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    madler#5 0x4018d8 in _start (/work/spop/zlib-ng/minigzip+0x4018d8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 _IO_fwrite
==17466==ABORTING

During compilation the following warnings point to a missing definition:

/home/spop/s/zlib-ng/test/minigzip.c:154:31: warning: implicit declaration of function 'fdopen' is invalid in C99 [-Wimplicit-function-declaration]
    gz->file = path == NULL ? fdopen(fd, gz->write ? "wb" : "rb") :
                              ^
/home/spop/s/zlib-ng/test/minigzip.c:154:29: warning: pointer/integer type mismatch in conditional expression ('int' and 'FILE *' (aka 'struct _IO_FILE *')) [-Wconditional-type-mismatch]
    gz->file = path == NULL ? fdopen(fd, gz->write ? "wb" : "rb") :
                            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/spop/s/zlib-ng/test/minigzip.c:504:36: warning: implicit declaration of function 'fileno' is invalid in C99 [-Wimplicit-function-declaration]
            file = PREFIX(gzdopen)(fileno(stdin), "rb");
                                   ^
/home/spop/s/zlib-ng/test/minigzip.c:508:36: warning: implicit declaration of function 'fileno' is invalid in C99 [-Wimplicit-function-declaration]
            file = PREFIX(gzdopen)(fileno(stdout), outmode);
                                   ^
/home/spop/s/zlib-ng/test/minigzip.c:534:48: warning: implicit declaration of function 'fileno' is invalid in C99 [-Wimplicit-function-declaration]
                        file = PREFIX(gzdopen)(fileno(stdout), outmode);
                                               ^
5 warnings generated.

and looking at stdio.h that defines fdopen we see that it is only defined under
__USE_POSIX:

 #ifdef	__USE_POSIX
/* Create a new stream that refers to an existing system file descriptor.  */
extern FILE *fdopen (int __fd, const char *__modes) __THROW __wur;
 #endif

This patch fixes the compiler warnings and the runtime ASAN error.
hzhuang1 pushed a commit to Linaro/warpdrive-zlib that referenced this issue Jul 31, 2019
@Dead2
Fix test/example.c when compiled with ASAN
6d084c1 
Before this patch

cmake -DWITH_SANITIZERS=1
make
make test

used to fail with:

Running tests...
Test project /home/hansr/github/zlib/zlib-ng
    Start 1: example
1/2 Test madler#1: example ..........................***Failed    0.14 sec
    Start 2: example64
2/2 Test madler#2: example64 ........................***Failed    0.13 sec

==11605==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x62e000000595,0x62e0000053b5) and [0x62e000000400, 0x62e000005220) overlap
    #0 0x7fab3bcc9662 in __asan_memcpy (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8c662)
    madler#1 0x40f936 in memcpy /usr/include/x86_64-linux-gnu/bits/string3.h:53
    madler#2 0x40f936 in read_buf /home/spop/s/zlib-ng/deflate.c:1122
    madler#3 0x410458 in deflate_stored /home/spop/s/zlib-ng/deflate.c:1394
    madler#4 0x4133d7 in zng_deflate /home/spop/s/zlib-ng/deflate.c:945
    madler#5 0x402253 in test_large_deflate /home/spop/s/zlib-ng/test/example.c:275
    madler#6 0x4014e8 in main /home/spop/s/zlib-ng/test/example.c:536
    madler#7 0x7fab3b89382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    madler#8 0x4018e8 in _start (/work/spop/zlib-ng/example+0x4018e8)

0x62e000000595 is located 405 bytes inside of 40000-byte region [0x62e000000400,0x62e00000a040)
allocated by thread T0 here:
    #0 0x7fab3bcd579a in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9879a)
    madler#1 0x40147a in main /home/spop/s/zlib-ng/test/example.c:516

0x62e000000400 is located 0 bytes inside of 40000-byte region [0x62e000000400,0x62e00000a040)
allocated by thread T0 here:
    #0 0x7fab3bcd579a in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9879a)
    madler#1 0x40147a in main /home/spop/s/zlib-ng/test/example.c:516

SUMMARY: AddressSanitizer: memcpy-param-overlap ??:0 __asan_memcpy
==11605==ABORTING

fix bug madler#183 following recommendations of Mika Lindqvist

 > the problem is in line c_stream.avail_in = (unsigned int)comprLen/2;
 > which feeds it too much data ... it should cap it to
 > c_stream.next_out - compr instead.
hzhuang1 pushed a commit to Linaro/warpdrive-zlib that referenced this issue Jul 31, 2019
@Dead2
fix oss-fuzz/11323: clear out s->prev buffer
6b5e2dd 
zlib-ng compiled with MSAN used to fail with:

SUMMARY: MemorySanitizer: use-of-uninitialized-value /src/zlib-ng/match.c:473:60 in longest_match
Exiting

  Uninitialized value was stored to memory at
    #0 0x7fcaced77645 in fill_window_sse /src/zlib-ng/arch/x86/fill_window_sse.c:84:17
    madler#1 0x7fcaced7d3d4 in deflate_quick /src/zlib-ng/arch/x86/deflate_quick.c:230:13
    madler#2 0x7fcaced2f54b in zng_deflate /src/zlib-ng/deflate.c:951:18
    madler#3 0x4a04e9 in test_large_deflate /src/zlib-ng/test/example.c:266:11
    madler#4 0x4a38d2 in main /src/zlib-ng/test/example.c:539:5
    madler#5 0x7fcace96a82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

  Uninitialized value was created by a heap allocation
    #0 0x45bf70 in malloc /src/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:910
    madler#1 0x7fcaced26cd9 in zng_deflateInit2_ /src/zlib-ng/deflate.c:315:26
    madler#2 0x7fcaced2605a in zng_deflateInit_ /src/zlib-ng/deflate.c:224:12
    madler#3 0x4a03c5 in test_large_deflate /src/zlib-ng/test/example.c:255:11
    madler#4 0x4a38d2 in main /src/zlib-ng/test/example.c:539:5
    madler#5 0x7fcace96a82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
This was referenced Aug 13, 2020
Closed
Closed
jinfeihan57 pushed a commit to minchai23/zlib that referenced this issue Sep 15, 2020
@kuba--
Merge pull request madler#1 from kuba--/msvc
a18471c 
Support for MSVC
nitro404 pushed a commit to Telefrag-Software/zlib that referenced this issue Jul 6, 2021
@ruslo
Merge pull request madler#1 from hjmallon/hunter-1.2.11
fcf6828 
Hunterized ZLIB 1.2.11
Lecrapouille pushed a commit to Lecrapouille/zlib that referenced this issue Sep 5, 2021
@Lecrapouille
oss-fuzz/11360: clear out s->prev buffer to avoid undefined behavior
b0f57e3 
this patch fixes a use of uninitialized value discovered by one of the fuzzers
of the oss-fuzz project:
https://github.com/google/oss-fuzz/blob/master/projects/zlib/example_dict_fuzzer.c
clang's memory sanitizer fails with:

==1==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x5930dd in slide_hash zlib/deflate.c:222:20
    madler#1 0x589461 in fill_window zlib/deflate.c:1558:13
    madler#2 0x59828f in deflate_rle zlib/deflate.c:2119:13
    madler#3 0x590614 in deflate zlib/deflate.c:1045:41
    madler#4 0x4a2d56 in test_dict_deflate /src/example_dict_fuzzer.c:79:11
    madler#5 0x4a3e9b in LLVMFuzzerTestOneInput /src/example_dict_fuzzer.c:156:3
    madler#6 0x4ed04b in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
    madler#7 0x4a4ff6 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
    madler#8 0x4b5e1a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:713:9
    madler#9 0x4a4121 in main /src/libfuzzer/FuzzerMain.cpp:20:10
    madler#10 0x7f3d7a13b82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
    madler#11 0x41ed08 in _start
  Uninitialized value was created by a heap allocation
    #0 0x45fa10 in malloc /src/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:911
    madler#1 0x586920 in deflateInit2_ zlib/deflate.c:320:27
    madler#2 0x4a2a24 in test_dict_deflate /src/example_dict_fuzzer.c:61:11
    madler#3 0x4a3e9b in LLVMFuzzerTestOneInput /src/example_dict_fuzzer.c:156:3
    madler#4 0x4ed04b in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
    madler#5 0x4a4ff6 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
    madler#6 0x4b5e1a in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:713:9
    madler#7 0x4a4121 in main /src/libfuzzer/FuzzerMain.cpp:20:10
    madler#8 0x7f3d7a13b82f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
GerHobbelt pushed a commit to GerHobbelt/zlib that referenced this issue Nov 20, 2021
@nmoinvaz @Dead2
Fixed wrong size being used in calloc in test_deflate_set_header.
9abe04b 
    CID 293478 (madler#1 of 1): Wrong size argument (SIZEOF_MISMATCH)
    suspicious_sizeof: Passing argument 1UL to function calloc that returns a pointer of type zng_gz_header * is suspicious because a multiple of sizeof (zng_gz_header) /*80*/ is expected.
GerHobbelt pushed a commit to GerHobbelt/zlib that referenced this issue Nov 20, 2021
@nmoinvaz @Dead2
Fixed ubsan warning in gzfread due to size_t overflow. madler#783
48c0891 
gzread.c:398:18: runtime error: unsigned integer overflow: 2 * 18446744073709551615 cannot be represented in type 'unsigned long'
    #0 0x10009d31e in zng_gzfread gzread.c:398
    madler#1 0x100005b1a in test_gzio example.c:213
    madler#2 0x10001093b in main example.c:1034
    madler#3 0x7fff71f57cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8)
GerHobbelt pushed a commit to GerHobbelt/zlib that referenced this issue Nov 20, 2021
@nmoinvaz @Dead2
Fixed ubsan error when building tree with no symbols. madler#782
f1f775d 
When there are no symbols in the tree we skip build_tree calculations and emit a block using static tree with no codes.

trees.c:357:19: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned long'
    #0 0x1000ed79b in build_tree trees.c:357
    madler#1 0x1000ea3f5 in zng_tr_flush_block trees.c:649
    madler#2 0x100090ab0 in deflate_slow deflate_slow.c:131
    madler#3 0x1000572bc in zng_deflate deflate.c:990
    madler#4 0x1000aecd3 in gz_comp gzwrite.c:125
    madler#5 0x1000b05df in zng_gzclose_w gzwrite.c:511
    madler#6 0x1000967a4 in zng_gzclose gzlib.c:253
    madler#7 0x100004f70 in test_gzio example.c:133
    madler#8 0x100010c5b in main example.c:1034
    madler#9 0x7fff71f57cc8 in start+0x0 (libdyld.dylib:x86_64+0x1acc8)
@jzer0 jzer0 mentioned this issue Dec 13, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@madler @lekanteto