<html>
    <head>
      <base href="https://llvm.org/bugs/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - [ASAN] libasan fails to initialize with upstream glibc in use"
   href="https://llvm.org/bugs/show_bug.cgi?id=27310">27310</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>[ASAN] libasan fails to initialize with upstream glibc in use
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libraries
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>trunk
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Miscellaneous Instrumentation passes
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>ilmalakhovthefirst@gmail.com
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>kcc@google.com, llvm-bugs@lists.llvm.org
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Hi.

 It seems that AddressSanitizer doesn't allow for calls to malloc() while
"asan_init_is_running" which would result in assertion failure due to recursive
invocation of AsanInitInternal(). Taking into account that the initialization
of
libasan relies on calls to many external functions, how is it going to pass if
some of the latter start calling malloc() as they are reworked?

 That's exactly what happened to `dlsym (RTLD_NEXT, . . .)' in upstream glibc
(a future glibc-2.24) after it had been fixed to report errors via dlerror()
(see <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=19509">https://sourceware.org/bugzilla/show_bug.cgi?id=19509</a> for details).
Because
this function is used to initialize interceptors the first unresolved symbol is
likely to break libasan.


 Here is a trivial example demonstrating this issue:

$ cat ./test.c

int
main ()
{
  return 0;
}

$ clang -m32 ./test.c -fsanitize=address -g

$ gdb ./a.out

. . .

#0  __asan::AsanInitFromRtl () at
llvm/projects/compiler-rt/lib/asan/asan_rtl.cc:561
#1  0x08066ab5 in __asan::Allocator::Allocate (this=0x8179a60
<__asan::instance>, size=80, alignment=8, stack=0xffffbf40,
    alloc_type=__asan::FROM_MALLOC, can_fill=true) at
llvm/projects/compiler-rt/lib/asan/asan_allocator.cc:326
#2  0x08063847 in __asan::asan_malloc (size=80, stack=0xffffbf40)
    at llvm/projects/compiler-rt/lib/asan/asan_allocator.cc:726
#3  0x08103f92 in __interceptor_malloc (size=80) at
llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:53
#4  0xf7fe8bd9 in _dl_signal_error (errcode=0, objname=0xffffcdb4 "./a.out",
    occation=<optimized out>, errstring=0xffffc800 "undefined symbol:
__isoc99_printf") at dl-error.c:90
#5  0xf7fe8d98 in _dl_signal_cerror (errcode=errcode@entry=0,
    objname=objname@entry=0xffffcdb4 "./a.out",
    occation=occation@entry=0xf8006c2a <error: Cannot access memory at address
0xf8006c2a>,
    errstring=0xffffc800 "undefined symbol: __isoc99_printf") at dl-error.c:155
#6  0xf7fe3bd6 in _dl_lookup_symbol_x (undef_name=undef_name@entry=0x813e40f
"__isoc99_printf", undef_map=undef_map@entry=0xf7ffd918,
    ref=ref@entry=0xffffc91c, symbol_scope=<optimized out>, version=<optimized
out>, type_class=<optimized out>, flags=<optimized out>,
    skip_map=<optimized out>) at dl-lookup.c:870
#7  0xf7eb25b7 in do_sym (handle=<optimized out>, name=0x813e40f
"__isoc99_printf", who=<optimized out>, vers=<optimized out>,
    flags=<optimized out>) at dl-sym.c:161
#8  0xf7eb29ad in _dl_sym (handle=<optimized out>, name=<optimized out>,
who=<optimized out>) at dl-sym.c:273
#9  0xf7f55dd1 in dlsym_doit (a=0xffffcac0) at dlsym.c:50
#10 0xf7fe8e13 in _dl_catch_error (objname=objname@entry=0x81a43ec
<calloc_memory_for_dlsym+12>,
    errstring=errstring@entry=0x81a43f0 <calloc_memory_for_dlsym+16>,
mallocedp=mallocedp@entry=0x81a43e8 <calloc_memory_for_dlsym+8>,
    operate=0xf7f55db0 <dlsym_doit>, args=0xffffcac0) at dl-error.c:187
#11 0xf7f5636f in _dlerror_run (operate=operate@entry=0xf7f55db0 <dlsym_doit>,
args=args@entry=0xffffcac0) at dlerror.c:163
#12 0xf7f55e3b in __dlsym (handle=0xffffffff, name=0x813e40f "__isoc99_printf")
at dlsym.c:70
#13 0x081137aa in __interception::GetRealFunctionAddress (func_name=0x813e40f
"__isoc99_printf",
    func_addr=0x81a2af0 <__interception::real___isoc99_printf>, real=134904400,
wrapper=134904400)
    at llvm/projects/compiler-rt/lib/interception/interception_linux.cc:23
#14 0x080ee703 in InitializeCommonInterceptors ()
    at
llvm/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:5563
#15 __asan::InitializeAsanInterceptors () at
llvm/projects/compiler-rt/lib/asan/asan_interceptors.cc:706
#16 0x08110bfd in __asan::AsanInitInternal () at
llvm/projects/compiler-rt/lib/asan/asan_rtl.cc:444
#17 0xf7fe910c in _dl_init (main_map=0xf7ffd918, argc=1, argv=0xffffcc04,
env=0xffffcc0c) at dl-init.c:105
#18 0xf7fdaadf in _dl_start_user () from /lib/ld-linux.so.2</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>