search for: threadstat

...to Hi Renato, So the problem is only with the tls emulation, right? I don't know what it worth to add __thread support to android, and whether somebody is going to address it soon. But I think we can make the tls emulation _much_ cleaner. First, we need to put all tsan per-thread data into ThreadState object, accesses to ThreadState are already wrapped into cur_thread() function. So now we have a single function to modify, no macros spread across the codebase, no new files, etc. Then, I've looked at pthread_getspecific code in bionic and it is actually quite fast and does not call any other...

On Tue, Aug 18, 2015 at 8:28 PM, Kostya Serebryany <kcc at google.com> wrote: > +dvyukov > > On Mon, Aug 17, 2015 at 8:37 AM, Renato Golin <renato.golin at linaro.org> > wrote: >> >> Folks, >> >> The review of patch http://reviews.llvm.org/D11532 is extremely slow >> due to the number of hacks, left-overs and general undesired changes >>

...g engineering reasons, it's not > possible to do it, then the reasons to do TLS emulation are thoroughly > justified. Right now, it's just a hunch. > > >> But I think we can make the tls emulation _much_ cleaner. First, we >> need to put all tsan per-thread data into ThreadState object, accesses >> to ThreadState are already wrapped into cur_thread() function. So now >> we have a single function to modify, no macros spread across the >> codebase, no new files, etc. > > I'm no expert in that field, but this sounds like a good plan. Doesn't &...

...onical pointer, in this case “0x00486000000025df”. This happens at wrap_OSSpinLockLock+17, which is just after the prologue and just after calling cur_thread(). So I’d say it happens when we’re dereferencing the pointer returned by cur_thread(). On OS X, we’re doing this trick where we store the ThreadState pointer in the shadow memory. Could it be that something actually read/wrote the memory that is backed by the same place as the shadow memory? Does “0x00486000000025df” like a reasonable content of a shadow cell? Kuba > On 21 Jan 2016, at 22:32, Kostya Serebryany <kcc at google.com> w...

...063d5946 __sanitizer::internal_sched_yield() + 6 3 libclang_rt.tsan_osx_dynamic.dylib 0x0000000106395495 wrap_pthread_create + 341 4 ??? 0x0000000000002006 0 + 8198 Thread 8: 0 libclang_rt.tsan_osx_dynamic.dylib 0x00000001063cb015 __tsan::MetaMap::FreeRange(__tsan::ThreadState*, unsigned long, unsigned long, unsigned long) + 149 Thread 9: 0 libsystem_kernel.dylib 0x00007fff98f915c2 swtch_pri + 10 1 libsystem_pthread.dylib 0x00007fff93b5d381 sched_yield + 11 2 libclang_rt.tsan_osx_dynamic.dylib 0x00000001063d5946 __sanitizer::internal_sched_yield()...

Hi all, I'm planning to migrate my courier-imap imap server to dovecot, but I'm experiencing a strange issue with fts-lucene plugin. Basically, every time I start a search, the log starts to write: Apr 05 19:30:53 indexer: Error: Indexer worker disconnected, discarding 1 requests for XXXXXX Apr 05 19:30:53 indexer-worker(XXXXX): Fatal: master: service(indexer-worker): child 809 killed

...6000000025df”. This happens at wrap_OSSpinLockLock+17, >> which is just after the prologue and just after calling cur_thread(). So >> I’d say it happens when we’re dereferencing the pointer returned by >> cur_thread(). On OS X, we’re doing this trick where we store the >> ThreadState pointer in the shadow memory. Could it be that something >> actually read/wrote the memory that is backed by the same place as the >> shadow memory? >> >> Does “0x00486000000025df” like a reasonable content of a shadow cell? > > > > Yes, it looks like a reasona...

...to -Werror: > > /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/projects/compiler-rt/lib/tsan/rtl/tsan_rtl_mutex.cc:460:6: > error: stack frame size of 536 bytes in function > '__tsan::ReportDeadlock' [-Werror,-Wframe-larger-than] > void ReportDeadlock(ThreadState *thr, uptr pc, DDReport *r) { > ^ > [ 93%] [ 93%] Building C object > lib/builtins/CMakeFiles/clang_rt.builtins-i386.dir/udivti3.c.o > [ 93%] Building CXX object > lib/tsan/CMakeFiles/clang_rt.tsan-x86_64.dir/rtl/tsan_suppressions.cc.o > 1 error gener...

On Wed, Jan 20, 2016 at 1:31 PM, Chris Matthews <chris.matthews at apple.com> wrote: > I worded that poorly, the Jenkins check I added will explain to the user > that we know this fails sometimes. > > On Jan 20, 2016, at 1:30 PM, Chris Matthews <chris.matthews at apple.com> > wrote: > > I have added a Jenkins check for this test, which explains why it fails on

..., then. > What about modifying the shadow-stack to use a thread-local linked list? > Another alternative is to add an additional parameter to every function containing the address of the head of the stack frame list. and have a good understanding of why. Many managed runtimes tackle this threadstate problem. > The ideal solution would be to walk the stack directly, without needing an auxiliary data structure. [...] which would likely be different on different processors and maybe different OSs as well. Yes, this requires platform-specific code. One of the unique design advantages of the...

On 26 August 2015 at 20:13, Jason Kim <jasonk at codeaurora.org> wrote: > I had been discussing the TSAN on android/aarch64 issues with the folks at thread-sanitizer at googlegroups.com for several months now. I had not explicitly been including llvm-dev (and you), and that was a mistake on my part. Palm-on-face? :-( Yup, that would have saved a lot of emails... :) > Patch Size!

On Wed, Aug 19, 2015 at 1:15 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 19 August 2015 at 11:29, Dmitry Vyukov <dvyukov at google.com> wrote: >> Wait, this change is not submitted yet, right? Or you mean mailing of >> this change in bad shape? > > Right. > > Jason has submitted high quality patches before, so this is in no way > a reprimand