Stack overflow in __ubsan_handle_dynamic_type_cache_miss (?) #80
Labels
compiler-rt:ubsan
Undefined behavior sanitizer
Comments
|
On Thu, Dec 26, 2019 at 02:09:33AM -0800, DimanNe wrote:
I am building both my application (gtest, to be precise) and `libc` from sources (branch `release/9.x`) with clang-9 with ubsan (`-fsanitize=undefined`).
Are you building the sanitzers themselve with ubsan?
Joerg
|
|
If I correctly understand that by sanitisers you mean I build
with standard |
|
Interesting, it appears the libcxxabi should not be compiled with
-fsanitize=vptr.
Try -fno-sanitize=vptr in libcxxabi, or blacklist some of the sources with
-fsanitize-blacklist.
…On Thu, Dec 26, 2019 at 2:30 AM DimanNe ***@***.***> wrote:
If I correctly understand that by sanitisers you mean
llvm-project/compiler-rt/lib/ubsan/, then no. I do not build them at all.
I build
- llvm-project/libcxx
- llvm-project/libcxxabi
- my app (which is gtest)
with standard clang-9 (which comes from Ubuntu 19.10 repos) with
-fsanitize=undefined option.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#80?email_source=notifications&email_token=AADG4SRQJ2P6KGGGUH4WZVTQ2SBT5A5CNFSM4J7KEWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHVMHZI#issuecomment-569033701>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADG4SVFSODIJGGB2RZN6VTQ2SBT5ANCNFSM4J7KEWLA>
.
|
|
Thank you for the hint! So, I added and verified that I have the option in compile lines for and it did not work. However, when I specified it globally: |
|
Yes, the order of the flags matters. -fno-sanitize subtracts from the
current set of sanitizers (reading the command line left-to-right), and
-fsanitize adds to it. You can run clang -### to see what it ends up with.
…On Fri, Dec 27, 2019 at 2:34 PM DimanNe ***@***.***> wrote:
Thank you for the hint!
------------------------------
So, I added -fno-sanitize=vptr directly into
contrib/llvm-project/libcxxabi/CMakeLists.txt:
add_compile_flags_if_supported(-fno-sanitize=vptr)
and verified that I have the option in compile lines for libcxxabi:
cd /home/dimanne/devel/build-scripts-Desktop-Debug-ubsan/contrib/llvm-project/libcxxabi/src &&
/usr/bin/clang++ -DHAVE___CXA_THREAD_ATEXIT_IMPL -D_LIBCPP_DISABLE_EXTERN_TEMPLATE
-D_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS
-D_LIBCXXABI_BUILDING_LIBRARY -D_LIBCXXABI_HAS_COMMENT_LIB_PRAGMA
-I/home/dimanne/devel/scripts/contrib/llvm-project/libcxxabi/include
-I/home/dimanne/devel/scripts/contrib/llvm-project/libcxx/include
-g -fPIC -Wno-everything -nostdinc++ -Werror=return-type -W -Wall -Wchar-subscripts
-Wconversion -Wmismatched-tags -Wmissing-braces -Wnewline-eof -Wunused-function
-Wshadow -Wshorten-64-to-32 -Wsign-compare -Wsign-conversion -Wstrict-aliasing=2
-Wstrict-overflow=4 -Wunused-parameter -Wunused-variable -Wwrite-strings -Wundef
-fno-sanitize=vptr # <---------------- here it is ----------------
-Wno-error -pedantic -fstrict-aliasing -funwind-tables -D_DEBUG -fno-omit-frame-pointer
-fno-optimize-sibling-calls -fsanitize-blacklist=/home/dimanne/devel/scripts/sanitiser_blacklist.txt
-fsanitize=undefined -std=c++11 -o CMakeFiles/cxxabi_static.dir/cxa_exception_storage.cpp.o
-c /home/dimanne/devel/scripts/contrib/llvm-project/libcxxabi/src/cxa_exception_storage.cpp
and it did *not* work.
Perhaps, I missed something. Maybe the order of some flags should be
different? May be -fsanitize=undefined should be followed by
-fno-sanitize=vptr?
------------------------------
However, when I specified it globally:
instead of add_compile_options(-fsanitize=undefined)
I have add_compile_options(-fsanitize=undefined -fno-sanitize=vptr)
my tests have passed perfectly fine.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#80?email_source=notifications&email_token=AADG4SUK23BP2XYO4IJTGELQ2Z7GTA5CNFSM4J7KEWLKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHX3KKQ#issuecomment-569357610>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADG4SSDOF5NVARRL7KWH43Q2Z7GTANCNFSM4J7KEWLA>
.
|
dnsampaio
pushed a commit
that referenced
this issue
Jan 10, 2020
Summary: This patch fixes pr23772 [ARM] r226200 can emit illegal thumb2 instruction: "sub sp, r12, #80". The violation was that SUB and ADD (reg, immediate) instructions can only write to SP if the source register is also SP. So the above instructions was unpredictable. To enforce that the instruction t2(ADD|SUB)ri does not write to SP we now enforce the destination register to be rGPR (That exclude PC and SP). Different than the ARM specification, that defines one instruction that can read from SP, and one that can't, here we inserted one that can't write to SP, and other that can only write to SP as to reuse most of the hard-coded size optimizations. When performing this change, it uncovered that emitting Thumb2 Reg plus Immediate could not emit all variants of ADD SP, SP #imm instructions before so it was refactored to be able to. (see test/CodeGen/Thumb2/mve-stacksplot.mir where we use a subw sp, sp, Imm12 variant ) It also uncovered a disassembly issue of adr.w instructions, that were only written as SUBW instructions (see llvm/test/MC/Disassembler/ARM/thumb2.txt). Reviewers: eli.friedman, dmgreen, carwil, olista01, efriedma Reviewed By: efriedma Subscribers: john.brawn, efriedma, ostannard, kristof.beyls, hiraditya, dmgreen, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70680
dnsampaio
pushed a commit
that referenced
this issue
Jan 14, 2020
Summary: This patch fixes pr23772 [ARM] r226200 can emit illegal thumb2 instruction: "sub sp, r12, #80". The violation was that SUB and ADD (reg, immediate) instructions can only write to SP if the source register is also SP. So the above instructions was unpredictable. To enforce that the instruction t2(ADD|SUB)ri does not write to SP we now enforce the destination register to be rGPR (That exclude PC and SP). Different than the ARM specification, that defines one instruction that can read from SP, and one that can't, here we inserted one that can't write to SP, and other that can only write to SP as to reuse most of the hard-coded size optimizations. When performing this change, it uncovered that emitting Thumb2 Reg plus Immediate could not emit all variants of ADD SP, SP #imm instructions before so it was refactored to be able to. (see test/CodeGen/Thumb2/mve-stacksplot.mir where we use a subw sp, sp, Imm12 variant ) It also uncovered a disassembly issue of adr.w instructions, that were only written as SUBW instructions (see llvm/test/MC/Disassembler/ARM/thumb2.txt). Reviewers: eli.friedman, dmgreen, carwil, olista01, efriedma, andreadb Reviewed By: efriedma Subscribers: gbedwell, john.brawn, efriedma, ostannard, kristof.beyls, hiraditya, dmgreen, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70680
jamesmth
pushed a commit
to jamesmth/llvm-project
that referenced
this issue
Dec 5, 2022
Since AGR clobbers CC it should not be used here. Fixes https://bugs.llvm.org/show_bug.cgi?id=47736. Review: Ulrich Weigand Differential Revision: https://reviews.llvm.org/D89034 (cherry picked from commit d851495) Co-authored-by: Jonas Paulsson <paulsson@linux.vnet.ibm.com>
jeffreytan81
pushed a commit
to jeffreytan81/llvm-project
that referenced
this issue
Sep 21, 2023
… provider We noticed some performance issue while in lldb-vscode for grabing the name of the SBValue. Profiling shows SBValue::GetName() can cause synthetic children provider of shared/unique_ptr to deference underlying object and complete it type. This patch lazily moves the dereference from synthetic child provider's Update() method to GetChildAtIndex() so that SBValue::GetName() won't trigger the slow code path. Here is the culprit slow code path: ``` ... frame llvm#59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt] ... frame llvm#67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt] frame llvm#68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt] frame llvm#69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt] ... frame llvm#78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt] frame llvm#79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt] frame llvm#80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt] frame llvm#81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt] frame llvm#82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt] frame llvm#83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt] ... ``` Differential Revision: https://reviews.llvm.org/D159542
jeffreytan81
pushed a commit
that referenced
this issue
Sep 21, 2023
#67069) We noticed some performance issue while in lldb-vscode for grabing the name of the SBValue. Profiling shows SBValue::GetName() can cause synthetic children provider of shared/unique_ptr to deference underlying object and complete it type. This patch lazily moves the dereference from synthetic child provider's Update() method to GetChildAtIndex() so that SBValue::GetName() won't trigger the slow code path. Here is the culprit slow code path: ``` ... frame #59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt] ... frame #67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt] frame #68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt] frame #69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt] ... frame #78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt] frame #79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt] frame #80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt] frame #81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt] frame #82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt] frame #83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt] ... ``` Differential Revision: https://reviews.llvm.org/D159542
RevySR
pushed a commit
to revyos/llvm-project
that referenced
this issue
Apr 3, 2024
* [Clang][XTHeadVector] implement 12.9 `vmul/vmulh/vmulhu/vmulhsu` * [Clang][XTHeadVector] test 12.9 `vmul/vmulh/vmulhu/vmulhsu`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am building both my application (gtest, to be precise) and
libcfrom sources (branchrelease/9.x) with clang-9 with ubsan (-fsanitize=undefined).When I try to run it, I get stackoverflow (due to infinite recursion) that looks like this:
According to the backtrace, my code is not even executed. Something wrong goes during global initialisation in GoogleTest.
I am sure I am missing something easy and obvious... Can you please help?
The text was updated successfully, but these errors were encountered: