AddressSanitizer change the behaviour of fmemopen

[dzamlo]

When compiling using AddressSanitizer, a call to fmemopen with a size of 0, return NULL.
Without AddressSanitizer, this works.
I made a gist with a minimal working example:
https://gist.github.com/dzamlo/676b75a21fa85ead765a

The code work fine when compiling with gcc -o test test.c, but fail when compilling with gcc -fsanitize=address -o test test.c. It the same with clang.

[mikea]

The code assertion-crashes for me both with gcc & head clang:

tmp/627.c:8: int main(int, char *): Assertion `f != ((void)0)' failed.

gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
clang version 3.8.0 (trunk 254306) (llvm/trunk 254310)

[dzamlo]

After some research, it seems that this is an issue with symbol versionning.

Prior to glibc 2.22, the implementation of fmemopen return NULL if size == 0. Since glibc 2.22, the implementation of fmemopen doesn't return NULL if size == 0.

You probably have an version of glibc <2.22, so the code fail without AddressSanitizer.

glibx export a versioned symbol for the new version. When compiling whithout -fsanitize=address, the new version is used. When with -fsanitize=address, the old version is used.

I don't think this is the intended behavior.

$ gcc -o test test.c
$ objdump -x test | grep fmemopen
0000000000000000       F *UND*  0000000000000000              fmemopen@@GLIBC_2.22

$ gcc -fsanitize=address -o test test.c
$ objdump -x test | grep fmemopen
0000000000000000       F *UND*  0000000000000000              fmemopen

[kcc]

What system are you using exactly? (glibc version? kernel version? distro?)

[dzamlo]

Arch Linux,
glibc 2.22

$uname -a
Linux sbrinz 4.2.5-1-ARCH #1 SMP PREEMPT Tue Oct 27 08:13:28 CET 2015 x86_64 GNU/Linux

$gcc --version
gcc (GCC) 5.2.0
Copyright © 2015 Free Software Foundation, Inc.
Ce logiciel est libre; voir les sources pour les conditions de copie.  Il n'y a PAS
GARANTIE; ni implicite pour le MARCHANDAGE ou pour un BUT PARTICULIER.

$clang --version
clang version 3.7.0 (tags/RELEASE_370/final)                                                                                         
Target: x86_64-unknown-linux-gnu                                                                                                     
Thread model: posix

[kcc]

Ah, so this is a very new system. I don't think we've played with such before.
I bet if you comment out the fmemopen interceptor in projects/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc
this will stop crashing.

[eugenis]

Yes, with ASan we use the old version. Unfortunately, that's how dlopen works (and by extension, ASan interceptors). I'd argue that you should not call fmemopen with 0 size if there are reasonably recent versions of glibc that do not support that.

[mikea]

There isn't any special logic handling failure cases for fmemopen. There is, however, a symbol versioning problem. I created #628 to track it.