[llvm-bugs] [Bug 48929] New: Infinite recursion in type_info::operator== under UBSan

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48929

            Bug ID: 48929
           Summary: Infinite recursion in type_info::operator== under
                    UBSan
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ubsan
          Assignee: unassignedbugs at nondot.org
          Reporter: tlively at google.com
                CC: llvm-bugs at lists.llvm.org

Apologies if this is the wrong component to file a bug on. It is definitely a
UBSan bug, but the relevant code is spread across compiler-rt, libc++, and
libc++abi.

I just investigated an issue in which using std::type_info::operator== produced
an infinite recursion with the following cycle of function calls:

RangeError: Maximum call stack size exceeded
    ...
    at std::type_info::operator==(std::type_info const&) const
    at is_equal(std::type_info const*, std::type_info const*, bool) 
    at __dynamic_cast (<anonymous>:wasm-function[40]:0x8fb)
    at __ubsan::checkDynamicType(void*, void*, unsigned long)
    at HandleDynamicTypeCacheMiss(__ubsan::DynamicTypeCacheMissData*, unsigned
long, unsigned long, __ubsan::ReportOptions)
    at __ubsan_handle_dynamic_type_cache_miss
    at std::type_info::operator==(std::type_info const&) const
    ...

Here is the reproducing program:

    // main.cpp
    #include <typeinfo>
    int main() {
      return typeid(int) == typeid(int)
    }


This infinite recursion happens when libc++abi is compiled with -Oz, but not
when it compiled with -O3. In the latter configuration, enough inlining and
follow-on optimizations happen to remove the call to std::type_info::operator==
under __dynamic_cast, preventing the infinite recursion. I found that adding
__attribute__((always_inline)) to std::type_info::operator== in libc++ was
sufficient to prevent the infinite recursion in the -Oz configuration as well.

This is certainly a niche configuration required to reproduce the bug, but it
seems that UBSan depending on optimizations to prevent infinite recursions is
not great, so possibly worth fixing.

The upstream workaround in Emscripten is here:
https://github.com/emscripten-core/emscripten/pull/13367.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210128/ad61c4bb/attachment-0001.html>