[Bug c++/88901] New: [9.0 Regression] ICE when using -fsanitize=pointer-compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88901 Bug ID: 88901 Summary: [9.0 Regression] ICE when using -fsanitize=pointer-compare Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dominik.stras...@onespin-solutions.com Target Milestone: --- Created attachment 45454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45454=edit Source code triggering the crash The attached sourced code yields a t.C:4:50: internal compiler error: tree check: did not expect class 'type', have 'type' (template_type_parm) in contains_placeholder_p, at tree.c:3795 when "-fsanitize=address -fsanitize=pointer-compare" is used. gcc 8.2 works fine. g++ -c -fsanitize=address -fsanitize=pointer-compare t.C This is g++ from git 2019/01/17
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #14 from dominik.stras...@onespin-solutions.com --- With the 9.0 version of libasan I also experience an additional crash which is 100% reproducible: buffer points to non-accessible memory: (gdb) p buffer $1 = (__sanitizer::u64 *) 0x7fff49eff000 (gdb) p *buffer Cannot access memory at address 0x7fff49eff000 log: ... ==56701==T7 TSDDtor ==56701==T7 exited ==56701==poisoning: 0x7fff38c62350 250 ==56701==T5 TSDDtor ==56701==poisoning: 0x7fff38c71480 3c8 ==56701==T5 exited ==56701==poisoning: 0x7fff38c76e10 128 [Thread 0x7fff21d46700 (LWP 63421) exited] Thread 8 "TclShellThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff20d44700 (LWP 63444)] 0x77360744 in __sanitizer::SizeClassAllocator64<__asan::AP64>::PackedCounterArray<__sanitizer::SizeClassAllocator64<__asan::AP64>::MemoryMapper>::Inc (this=0x7fff20d42cb0, i=662) at ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:377 377 buffer[index] += 1ULL << bit_offset; (gdb) where #0 0x77360744 in __sanitizer::SizeClassAllocator64<__asan::AP64>::PackedCounterArray<__sanitizer::SizeClassAllocator64<__asan::AP64>::MemoryMapper>::Inc (this=0x7fff20d42cb0, i=662) at ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:377 #1 0x7735fb93 in __sanitizer::SizeClassAllocator64<__asan::AP64>::ReleaseFreeMemoryToOS<__sanitizer::SizeClassAllocator64<__asan::AP64>::MemoryMapper> (free_array=0x604e, free_array_count=68304, chunk_size=64, allocated_pages_count=3872, memory_mapper=0x7fff20d42db0) at ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:498 #2 0x7735ea5e in __sanitizer::SizeClassAllocator64<__asan::AP64>::MaybeReleaseToOS (this=0x77534ea0 <__asan::instance>, class_id=4, force=false) at ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:840 #3 0x7735f289 in __sanitizer::SizeClassAllocator64<__asan::AP64>::ReturnToAllocator (this=0x77534ea0 <__asan::instance>, stat=0x7fff31ac8c40, class_id=4, chunks=0x7fff31abc130, n_chunks=126) at ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_primary64.h:130 #4 0x7735e06c in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >::Drain (this=0x7fff31abb0e0, c=0x7fff31abc120, allocator=0x77534ea0 <__asan::instance>, class_id=4, count=126) at ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:120 #5 0x7735d764 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >::Drain (this=0x7fff31abb0e0, allocator=0x77534ea0 <__asan::instance>) at ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_local_cache.h:74 #6 0x7735ba03 in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__asan::AP64>, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<__asan::AP64> >, __sanitizer::LargeMmapAllocator<__asan::AsanMapUnmapCallback, __sanitizer::LargeMmapAllocatorPtrArrayDynamic> >::SwallowCache (this=0x77534ea0 <__asan::instance>, cache=0x7fff31abb0e0) at ../../../../gcc-git/libsanitizer/sanitizer_common/sanitizer_allocator_combined.h:159 #7 0x7735a8c1 in __asan::Allocator::CommitBack (this=0x77534ea0 <__asan::instance>, ms=0x7fff31abb060, stack=0x7fff20d42fb0) at ../../../../gcc-git/libsanitizer/asan/asan_allocator.cc:698 #8 0x773560bd in __asan::AsanThreadLocalMallocStorage::CommitBack (this=0x7fff31abb060) at ../../../../gcc-git/libsanitizer/asan/asan_allocator.cc:857 #9 0x774af6a2 in __asan::AsanThread::Destroy (this=0x7fff31abb000) at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:102 #10 0x774af647 in __asan::AsanThread::TSDDtor (tsd=0x7fff5d292460) at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:95 #11 0x774a6dba in __asan::PlatformTSDDtor (tsd=0x7fff5d292460) at ../../../../gcc-git/libsanitizer/asan/asan_posix.cc:66 #12 0x7fff5d07ac22 in __nptl_deallocate_tsd () from /lib64/libpthread.so.0 #13 0x7fff5d07ae33 in start_thread () from /lib64/libpthread.so.0 #14 0x7fff59f8dbad in clone () from /lib64/libc.so.6
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791
--- Comment #13 from dominik.stras...@onespin-solutions.com ---
The crash is not 100% reproducible. Looks like it is a race.
I'll check whether I can give you access to a system on our side.
I also encountered a differnt crash:
[Switching to Thread 0x7fffb920b700 (LWP 45227)]
0x77357d76 in __asan::AsanThread::isUnwinding (this=0x7fffb9944000) at
../../../../gcc-git/libsanitizer/asan/asan_thread.h:126
126 bool isUnwinding() const { return unwinding_; }
(gdb) p unwinding_
Cannot access memory at address 0x7fffb9951e80
(gdb) up
#1 0x774a19ad in __asan::GetStackTrace (fast=true, context=0x0,
bp=140736299312784, pc=140737342216507, max_depth=100, stack=0x7fffb9209e00)
at ../../../../gcc-git/libsanitizer/asan/asan_stack.h:40
40 if ((t = GetCurrentThread()) && !t->isUnwinding()) {
#0 0x77357d76 in __asan::AsanThread::isUnwinding (this=0x7fffb92f9000)
at ../../../../gcc-git/libsanitizer/asan/asan_thread.h:126
#1 0x774a19ad in __asan::GetStackTrace (fast=true, context=0x0,
bp=140736316278416, pc=140737342216507, max_depth=100, stack=0x7fffba237e00)
at ../../../../gcc-git/libsanitizer/asan/asan_stack.h:40
#2 operator new (size=32) at
../../../../gcc-git/libsanitizer/asan/asan_new_delete.cc:104
#3 0x004f11b5 in
__gnu_cxx::new_allocator, std::allocator > >::allocate
(this=0x7fffba238928, __n=1)
at /local/strasser/gcc-git/include/c++/9.0.0/ext/new_allocator.h:114
#4 0x004ebf38 in
std::allocator_traits, std::allocator > > >::allocate (__a=..., __n=1)
at /local/strasser/gcc-git/include/c++/9.0.0/bits/alloc_traits.h:444
#5 0x004e4978 in std::_Vector_base, std::allocator >,
std::allocator,
std::allocator > > >::_M_allocate (this=0x7fffba238928, __n=1) at
/local/strasser/gcc-git/include/c++/9.0.0/bits/stl_vector.h:343
#6 0x005b61e3 in std::vector, std::allocator >,
std::allocator,
std::allocator > >
>::_M_allocate_and_copy<__gnu_cxx::__normal_iterator, std::allocator > const*,
std::vector,
std::allocator >, std::allocator, std::allocator > > > > > (this=0x7fffba238928,
__n=1, __first="SATEQC",
__last=) at
/local/strasser/gcc-git/include/c++/9.0.0/bits/stl_vector.h:1472
#7 0x005b3a5b in std::vector, std::allocator >,
std::allocator,
std::allocator > > >::operator= (this=0x7fffba238928, __x=std::vector of
length 1, capacity 1 = {...}) at
/local/strasser/gcc-git/include/c++/9.0.0/bits/vector.tcc:227
...
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #12 from dominik.stras...@onespin-solutions.com --- Created attachment 45434 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45434=edit Debug output in gdb
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #10 from dominik.stras...@onespin-solutions.com --- Looking at the backtrace, the effects are very different between gcc 7.4 and 9.0. Making it work on a different glibc wouldn't help for me. CentOs 7.5 == RHEL 7.5 which is the latest "commercial" Linux system. What could we do to make it work?
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #7 from dominik.stras...@onespin-solutions.com --- I canse it plays a role: I am running on a CentOS Linux release 7.5.1804 which has kernel version 3.10.0-862.11.6.el7.x86_64 and glibc glibc-2.17-222.el7.i686
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #6 from dominik.stras...@onespin-solutions.com --- Created attachment 45426 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45426=edit ASAN debug output
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #5 from dominik.stras...@onespin-solutions.com --- ASAN from git crashes like this. Looks like a double fault. SignalHandler_Unix.h is in my application's code. I've attached ASAN's debug output where I removed all messages talking about poisoning/unpoisoning as they look unrelated. #5 0x7f6fd264c005 in SYSTEM::handleSignalForThread (t=140117893179136) at SignalHandler_Unix.h:412 #6 0x7f6fd264c57f in SYSTEM::gBadSignalHandler (signalNr=11, info=0x7f6fbd3fb070, ctx=0x7f6fbd3faf40) at SignalHandler_Unix.h:478 #7 #8 __asan::GetCurrentThread () at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:415 #9 0x7f6ffa37c58d in __asan_handle_no_return () at ../../../../gcc-git/libsanitizer/asan/asan_rtl.cc:538 #10 0x7f6fd264c04e in SYSTEM::handleSignalForThread (t=140117893179136) at SignalHandler_Unix.h:423 #11 0x7f6fd264c57f in SYSTEM::gBadSignalHandler (signalNr=11, info=0x7f6fbd3fbd70, ctx=0x7f6fbd3fbc40) at SignalHandler_Unix.h:478 #12 #13 GetCurrentThread () at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:415 #14 __asan::GetCurrentTidOrInvalid () at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:429 #15 0x7f6ffa37a1ea in __asan::ReportGenericError (pc=140118247917729, bp=bp@entry=140117893172896, sp=sp@entry=140117893172888, addr=105827994255744, is_write=is_write@entry=false, access_size=access_size@entry=8, exp=0, fatal=true) at ../../../../gcc-git/libsanitizer/asan/asan_report.cc:459 #16 0x7f6ffa37aea8 in __asan::__asan_report_load8 (addr=) at ../../../../gcc-git/libsanitizer/asan/asan_rtl.cc:119 #17 0x7f6fd264c8a1 in SYSTEM::gBadSignalHandler (signalNr=11, info=0x7f6fbd3fd630, ctx=0x7f6fbd3fd500) at SignalHandler_Unix.h:502 #18 #19 __asan::AsanThread::SetThreadStackAndTls (this=this@entry=0x7f6fbc552000, options=) at ../../../../gcc-git/libsanitizer/asan/asan_thread.h:80 #20 0x7f6ffa37e619 in __asan::AsanThread::Init (this=this@entry=0x7f6fbc552000, options=options@entry=0x0) at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:223 #21 0x7f6ffa37ea64 in __asan::AsanThread::ThreadStart (this=0x7f6fbc552000, os_id=5519, signal_thread_is_registered=0x7f6fc29da978) at ../../../../gcc-git/libsanitizer/asan/asan_thread.cc:244 #22 0x7f6fd150de25 in start_thread () from /lib64/libpthread.so.0 #23 0x7f6fd01dcbad in clone () from /lib64/libc.so.6
[Bug sanitizer/88791] ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 --- Comment #3 from dominik.stras...@onespin-solutions.com --- Unfortunately my application is huge and spawns many threads. Can you propose some debugging aid. I am building gcc myself, so I can add anything to libasan that you want.
[Bug sanitizer/88791] New: ASAN deadlocks in threaded application
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88791 Bug ID: 88791 Summary: ASAN deadlocks in threaded application Product: gcc Version: 7.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dominik.stras...@onespin-solutions.com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- I have a threaded application which shows random crashes with ASAN. This is unfortunate but does not bother me too much. What is bothering me is that ASAN deadlocks after crashes. It looks like __asan::ReportDeadlySignal tries to acquire the __asan::thread_registry_placeholder lock which is already held by __sanitizer::ThreadRegistry::FinishThread Here are the two partial backtraces form my application: This is the thread which crashes: Thread 13 (Thread 0x7f35b94cc700 (LWP 53461)): #0 atomic_exchange<__sanitizer::atomic_uint32_t> (mo=__sanitizer::memory_order_acquire, v=2, a=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:66 #1 __sanitizer::BlockingMutex::Lock (this=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_linux.cc:525 #2 0x7f35f037bf76 in Lock (this=) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_thread_registry.h:84 #3 StartReporting (this=0x7f35c13e0f5f) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_report.cc:225 #4 __asan::ScopedInErrorReport::ScopedInErrorReport (this=0x7f35c13e0f5f, fatal=) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_report.cc:120 #5 0x7f35f0378970 in __asan::ReportDeadlySignal (signo=signo@entry=11, sig=...) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_report.cc:251 #6 0x7f35f0377b12 in __asan::AsanOnDeadlySignal (signo=11, siginfo=0x7f35c13e1bf0, context=0x7f35c13e1ac0) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_posix.cc:99 #7 #8 0x7f35f0398e17 in __sanitizer::ThreadContextBase::ThreadContextBase (this=0x7f35c469d000, tid=52) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_thread_registry.cc:20 #9 0x7f35f037f1a2 in AsanThreadContext (tid=52, this=) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_thread.h:42 #10 __asan::GetAsanThreadContext (tid=52) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_thread.cc:55 #11 0x7f35f0399217 in __sanitizer::ThreadRegistry::CreateThread (this=0x7f35f05f8ca0 <__asan::thread_registry_placeholder>, user_id=0, detached=, parent_tid=41, arg=0x7f35ba4f7550) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_thread_registry.cc:129 #12 0x7f35f037f2f8 in __asan::AsanThread::Create (start_routine=start_routine@entry=0x7f35d06f5785 , arg=arg@entry=0x616f0680, parent_tid=41, stack=stack@entry=0x7f35ba4f75e0, detached=) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_thread.cc:90 #13 0x7f35f02cf2a4 in __interceptor_pthread_create (thread=0x616f07f0, attr=, start_routine=0x7f35d06f5785 , arg=0x616f0680) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_interceptors.cc:264 #14 0x7f35d06f8453 in SYSTEM::DetachedThread::start (this=0x616f0680) at mythread.C:491 #15 0x7f35d06f7e8f in SYSTEM::DetachedThread::startAndWait (threads=...) at mythread.C:427 This is another thread: Thread 11 (Thread 0x7f35b9cf9700 (LWP 53463)): #0 atomic_exchange<__sanitizer::atomic_uint32_t> (mo=__sanitizer::memory_order_acquire, v=2, a=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:66 #1 __sanitizer::BlockingMutex::Lock (this=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_linux.cc:525 #2 0x7f35f03998b5 in GenericScopedLock (mu=0x7f35f05f8cb8 <__asan::thread_registry_placeholder+24>, this=) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_mutex.h:177 #3 __sanitizer::ThreadRegistry::FinishThread (this=0x7f35f05f8ca0 <__asan::thread_registry_placeholder>, tid=42) at ../../../../gcc-7.4.0/libsanitizer/sanitizer_common/sanitizer_thread_registry.cc:251 #4 0x7f35f037f6f7 in __asan::AsanThread::Destroy (this=0x7f35b6d9d000) at ../../../../gcc-7.4.0/libsanitizer/asan/asan_thread.cc:109 #5 0x7f35cf574c22 in __nptl_deallocate_tsd () from /lib64/libpthread.so.0 #6 0x7f35cf574e33 in start_thread () from /lib64/libpthread.so.0 #7 0x7f35ce0bbbad in clone () from /lib64/libc.so.6 So to me it looks like both threads try to lock __asan::thread_registry_placeholder
[Bug c++/71553] [6 regression]ICE in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71553 --- Comment #5 from dominik.stras...@onespin-solutions.com --- Works after applying the patch in my non-reduced test case, too. Thanks
[Bug sanitizer/67865] ASAN crashes on thread creation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67865 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from dominik.stras...@onespin-solutions.com --- Works fine with GCC 6.1, let's forget about this issue.
[Bug c++/71553] [6 regression]ICE in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71553 --- Comment #1 from dominik.stras...@onespin-solutions.com --- The ICE only occurs on -O2 and up, -O1 works.
[Bug c++/71553] [6 regression]ICE in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71553 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Component|tree-optimization |c++ Severity|normal |major
[Bug tree-optimization/71553] New: [6 regression]ICE in assign_temp, at function.c:961
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71553 Bug ID: 71553 Summary: [6 regression]ICE in assign_temp, at function.c:961 Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dominik.stras...@onespin-solutions.com Target Milestone: --- Created attachment 38709 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38709=edit reduced source code triggering the ICE The attached source core results in the ICE from $SUBJECT. The patch from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71210 is already applied. I didn't apply the patches from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69889 because I assumed that these are part of the 6.1 release.
[Bug sanitizer/67865] ASAN crashes on thread creation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67865 --- Comment #3 from dominik.stras...@onespin-solutions.com --- I can say that it works with gcc 4.8. Clang 3.7 could take a while because I suffer from an incompatibility between gcc and clang so I cannot bind my C++ libs compiled with gcc to a clang compiled binary. Is there a separate repo for libsanitize I could drop in ? glibc 2.12 is the glibc of RHEL 6, which should be quite popular. Btw. I see different crashes, and ~50% of the times I don't see a crash at all. Looks like a race. I'll investigate.
[Bug sanitizer/67865] New: ASAN crashes on thread creation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67865 Bug ID: 67865 Summary: ASAN crashes on thread creation Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dominik.stras...@onespin-solutions.com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Target Milestone: --- In my application, ASAN crashes with the following stack backtrace: ==1926==ERROR: AddressSanitizer: SEGV on unknown address 0x7f4e24fbd010 (pc 0x7f4e40dafc0b bp 0xffd8 sp 0x7f4e259cf1a0 T13) #0 0x7f4e40dafc0a in __sanitizer::DTLS_on_tls_get_addr(void*, void*) ../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_tls_get_addr.cc:85 #1 0x7f4e40d36925 in __interceptor___tls_get_addr ../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3873 #2 0x7f4e40db0483 in __lsan::DisabledInThisThread() ../../../../gcc-5.2.0/libsanitizer/lsan/lsan_common.cc:33 #3 0x7f4e40d23004 in Allocate ../../../../gcc-5.2.0/libsanitizer/asan/asan_allocator2.cc:382 #4 0x7f4e40d942fe in __interceptor_realloc ../../../../gcc-5.2.0/libsanitizer/asan/asan_malloc_linux.cc:60 #5 0x3dc3608b3e in pthread_getattr_np (/lib64/libpthread.so.0+0x3dc3608b3e) #6 0x7f4e40da6fe3 in __sanitizer::GetThreadStackTopAndBottom(bool, unsigned long*, unsigned long*) ../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:109 #7 0x7f4e40da750b in __sanitizer::GetThreadStackAndTls(bool, unsigned long*, unsigned long*, unsigned long*, unsigned long*) ../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_linux_libcdep.cc:303 #8 0x7f4e40d9dac4 in __asan::AsanThread::SetThreadStackAndTls() ../../../../gcc-5.2.0/libsanitizer/asan/asan_thread.cc:185 #9 0x7f4e40d9dcc1 in __asan::AsanThread::Init() ../../../../gcc-5.2.0/libsanitizer/asan/asan_thread.cc:144 #10 0x7f4e40d9de7e in __asan::AsanThread::ThreadStart(unsigned long) ../../../../gcc-5.2.0/libsanitizer/asan/asan_thread.cc:157 #11 0x3dc36079d0 in start_thread (/lib64/libpthread.so.0+0x3dc36079d0) #12 0x3dc2ee8b6c in __clone (/lib64/libc.so.6+0x3dc2ee8b6c) AddressSanitizer can not provide additional info. Additional information can be provided on request My executable has been compiled with: -fsanitize=address -fno-omit-frame-pointer -fstack-protector-all -O3 -g -D_REENTRANT -lpthread
[Bug sanitizer/67865] ASAN crashes on thread creation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67865 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Target||x86_64-unknown-linux-gnu Host||x86_64-unknown-linux-gnu Build||x86_64-unknown-linux-gnu --- Comment #1 from dominik.stras...@onespin-solutions.com --- Host system: CentOS release 6.4 (Final) glibc: glibc-2.12-1.132.el6.x86_64
[Bug c++/62305] throw segfaults on 64bit Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62305 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from dominik.stras...@onespin-solutions.com --- Problem has disappeared both due to code changes and cygwin/mingw updates.
[Bug c++/62305] New: throw segfaults on 64bit Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62305
Bug ID: 62305
Summary: throw segfaults on 64bit Cygwin
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominik.stras...@onespin-solutions.com
The symptoms of this problems are quite similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56747, however it is no *always*
cured by compiling with -O1. I tried compiling various source files I have with
-O0, then the problem vanished, but later reappeared on a different exception
path.
Another thing I tried was to put the function below into a separate file and
trying with optimization options which did not succeed. Is the problem maybe
located not in the catching function but in the cleanup regions of a the stack
between the throw and the catch ?
Host triple: x86_64-w64-mingw32-g++
The function catching the exception looks like this:
pairunsigned,unsigned
ExpRef::getConstRange(CompEnv rCompEnv,const NetReg crNetReg) const {
CompEnv::BoolVarToggler noSideEffects(rCompEnv.deactivateSideEffects());
unsigned uiWidth = 0;
try {
uiWidth = crNetReg.width(rCompEnv);
if (!usePreciseConstRange) {
return pairunsigned,unsigned(uiWidth-1,0);
}
Sel::LLRes llIndex = checkRange(rCompEnv);
if (!llIndex.isEmpty() !llIndex.isPartiallyEmpty()
llIndex.isConstant()) {
assert(llIndex.left() = llIndex.right());
assert(llIndex.right() = 0);
assert(llIndex.llLeft() = llIndex.llRight());
// width might be 0 in error case ...
assert(llIndex.llLeft()+1 = uiWidth);
return pairunsigned,unsigned(llIndex.llLeft(),llIndex.llRight());
}
} catch(...) {
// do nothing
}
return pairunsigned,unsigned(uiWidth-1,0);
}
The crash looks like this:
gdb: unknown target exception 0x20474343 at 0x7fefcc8940d
Program received signal ?, Unknown signal.
[Switching to Thread 4920.0x1124]
0x07fefcc8940d in RaiseException ()
from C:\Windows\system32\KernelBase.dll
(gdb) where
#0 0x07fefcc8940d in RaiseException ()
from C:\Windows\system32\KernelBase.dll
#1 0x6144cd4d in libgcc_s_seh-1!_Unwind_RaiseException ()
from
C:\cygwin64\home\cve\distributions\unreleased_distributions\Distr\latest\onespin360\onespin\bin\cygwin64\libgcc_s_seh-1.dll
#2 0x6fcb76c8 in libstdc++-6!.cxa_throw ()
from
C:\cygwin64\home\cve\distributions\unreleased_distributions\Distr\latest\onespin360\onespin\bin\cygwin64\libstdc++-6.dll
Stackframe #3 is the throw location.
I know that this is not very much I have here for diagnosis, so it is morea
call for help on debugging this crash. Is there a way to find out which
function is currently unwound ?
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from dominik.stras...@onespin-solutions.com --- I see the point, so no need to change anything.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|RESOLVED|NEW Version|4.7.0 |4.8.1 Resolution|FIXED |--- --- Comment #16 from dominik.stras...@onespin-solutions.com --- The situation is much improved in 4.8.1, but still not usable for me in bigger configurations: time ./a.out 1 real0m0.907s user0m0.904s sys0m0.003s time ./a.out 2 real0m3.713s user0m3.708s sys 0m0.001s time ./a.out 4 real 0m13.820s user0m13.812s sys 0m0.001s time ./a.out 8 real0m56.759s user0m56.729s sys0m0.001s Still O(n^2). (I modified the test program to use argv[1] as loop counter. W/o _GLIBCXX_DEBUG: time ./a.out 1 real0m0.008s user0m0.006s sys0m0.002s ./a.out 2 real0m0.013s user0m0.008s sys0m0.004s ./a.out 4 real0m0.013s user0m0.013s sys0m0.000s ./a.out 8 real0m0.026s user0m0.024s sys0m0.002s Which shows O(n) behavior.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #17 from dominik.stras...@onespin-solutions.com --- Created attachment 30350 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30350action=edit New testcase
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Attachment #27332|0 |1 is obsolete|| Attachment #30350|0 |1 is obsolete|| --- Comment #18 from dominik.stras...@onespin-solutions.com --- Created attachment 30351 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30351action=edit Really new testcase
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #21 from dominik.stras...@onespin-solutions.com --- How can I help ? My goal is to run our entire regression test suite with STL debugging switched on as this is great for quality assurance. Having fought several problems, this now seems to be my final obstacle. After one year I now have a fix in a GCC release but unfortunately still no cigar. If you point me to sth. where I can look at I will happily try to contribute.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #14 from dominik.stras...@onespin-solutions.com 2012-06-11 15:05:43 UTC --- Is there a chance to get this into 4.7.1 ?
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #3 from dominik.stras...@onespin-solutions.com 2012-06-11 15:10:49 UTC --- I get the point. However, I could imagine that it is a quite common scenario to have a binary contributed C++ lib. Mixing debug/non-debug is impossible due to name mangling, however you can get random behavior if debug-enabled containers are returned. It took me quite a while to find out what was going wrong. Maybe some annotation for the linker could help here. I see that there's a general problem with overloading on function return values, but usually this is under the control of the user.
[Bug libstdc++/53324] New: Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 Bug #: 53324 Summary: Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dominik.stras...@onespin-solutions.com Created attachment 27373 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27373 Example to illustrate the problem The attached example mixes std::deque compiled without _GLIBCXX_DEBUG. The non-_GLIBCXX_DEBUG comes in the original from a binary supplied lib. IMHO the mixture should either work or disallowed by making std::deque not assignable to a std::__debug::deque.
[Bug libstdc++/53263] New: priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 Bug #: 53263 Summary: priority_queue is very slow if -D_GLIBCXX_DEBUG is used Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dominik.stras...@onespin-solutions.com Created attachment 27332 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27332 Minimalistic example demonstrating the problem I've measured the most simplistic usage of priority queue. With 5,000 elements, the run time is: real0m0.005s user0m0.002s sys 0m0.002s With 10,000 elements, the run time is: real0m0.006s user0m0.002s sys 0m0.002s If I switch on -D_GLIBCXX_DEBUG, the situation changes: 5,000 elements: real0m11.216s user0m11.210s sys 0m0.003s 10,000 elements: real0m48.354s user0m48.344s sys 0m0.003s 20,000 elements: real2m56.971s user2m56.941s sys 0m0.002s So in addition to some overhead, there seems to be some quadratic behavior inside the debug version as the run time is 4x for 2x elements.
[Bug libstdc++/53263] priority_queue is very slow if -D_GLIBCXX_DEBUG is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53263 --- Comment #3 from dominik.stras...@onespin-solutions.com 2012-05-07 12:38:26 UTC --- (In reply to comment #1) I don't think we are making any promises in terms of debug-mode performance. Is it better for other debug-mode implementations doing checks of similar strength? I see that the other containers have a performance which is comparable to the non-debug counterpart. priority_queue just kills some of my tests as it doesn't return after hours.
