http://llvm.org/bugs/show_bug.cgi?id=18058

            Bug ID: 18058
           Summary: UBSan SEGFAULTs rendering memory at 0x00000001
           Product: compiler-rt
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected]
    Classification: Unclassified

I'm trying to run some code through UBSan, but it crashes when trying to print
memory at address 0x00000001. The code in question comes from
boost::serialization 1.54:

boost/serialization/void_cast.hpp:187:13
    // note:I wanted to display from 0 here, but at least one compiler
    // treated 0 by not shifting it at all.
    reinterpret_cast<std::ptrdiff_t>(
        static_cast<Derived *>(
            reinterpret_cast<Base *>(1)
        )
    ) - 1


UBSan crashes because it detects a misaligned downcasts, after which it tries
to read the memory at 0xx00000001:

    /boost/serialization/void_cast.hpp:187:13: runtime error: downcast of
        misaligned address 0x00000001 for type 'BundleRFRead',
        which requires 4 byte alignment
    0x00000001: note: pointer points here

    Program received signal SIGSEGV, Segmentation fault.
    0x089c36dd in getMemoryLocation () at
      llvm/projects/compiler-rt/lib/ubsan/ubsan_diag.cc:191
    191        Printf("%s%02x", (P % 8 == 0) ? "  " : " ", C);


This is on ToT, with the backtrace as follows:

    #0  0x089c36dd in getMemoryLocation ()
      at llvm/projects/compiler-rt/lib/ubsan/ubsan_diag.cc:191
    #1  ~Diag ()
      at llvm/projects/compiler-rt/lib/ubsan/ubsan_diag.cc:271
    #2  0x089c412f in handleTypeMismatchImpl ()
      at llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers.cc:52
    #3  0x089c3b8f in __ubsan_handle_type_mismatch ()
      at llvm/projects/compiler-rt/lib/ubsan/ubsan_handlers.cc:56

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs

Reply via email to