search for: helgrind

...#39;t see why you'd need to add another word. The > PTHREAD_MUTEX_ERRORCHECK attribute has been part of POSIX since 1997, so > I'd expect it to be supported everywhere. > PTHREAD_MUTEX_ERRORCHECK detects the deadlock that already happened. tsan's deadlock detector (as well as helgrind and many other similar tools) detects lock order inversion, i.e. a situation which may potentially lead to a deadlock. --kcc -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140609/ca54f5c5/attachment.html&gt...

On Mon, Jun 9, 2014 at 1:21 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 9 Jun 2014, at 10:19, Kostya Serebryany <kcc at google.com> wrote: > > > tsan's deadlock detector (as well as helgrind and many other similar > tools) detects lock order inversion, i.e. a situation which may potentially > lead to a deadlock. > > Yes, that's what WITNESS does in the FreeBSD kernel. The line after the > one you quoted mentioned the port of this to userspace pthreads. > Did it...

...ode). Strictly speaking -- all these cases are bugs, according to either C or C++ standard, and asan does not impose more restrictions than the standard. Note, that the hacks like these hurt not only address safety checkers like asan/memcheck/drmemory/SAFEcode/etc, but also race detectors like tsan/helgrind/drd/etc. We still have lots of code with these intentional OOB accesses and we want to test it. In most cases I've met so far, the developers decided to actually fix the bugs according to the C++ standard and require the memory allocation to have up to 7 extra bytes. I do expect that sometimes...

...ing -- all these cases are bugs, according to either C or C++ > standard, and asan does not impose more restrictions than the standard. > Note, that the hacks like these hurt not only address safety checkers like > asan/memcheck/drmemory/SAFEcode/etc, but also race detectors like > tsan/helgrind/drd/etc. > > We still have lots of code with these intentional OOB accesses and we want to > test it. > In most cases I've met so far, the developers decided to actually fix the bugs > according to the C++ standard and require the memory allocation to have up to 7 > extra byte...

On Aug 24, 2009, at 1:32 AM, Duncan Sands wrote: > unfortunately, race detectors like helgrind don't like this kind of > thing, and report it as a race. Last time I asked about it I was > told that fixing it would be too hard/expensive. I know, and it's somewhat unfortunate. However, this path is extremely hot in LLC, and was significantly contended using only two threads....

Hi Kostya, > [resurrecting an old mail thread about AddressSanitizer false positive caused by > load widening] > > Once the Attribute::AddressSafety is set by clang (a separate patch), fixing > this bug may look as simple as this: I don't get the point of an attribute. There's plenty of code out there that does wide loads like this directly (without them being created by

...bugs, according to either C or >> C++ >> standard, and asan does not impose more restrictions than the standard. >> Note, that the hacks like these hurt not only address safety checkers like >> asan/memcheck/drmemory/**SAFEcode/etc, but also race detectors like >> tsan/helgrind/drd/etc. >> >> We still have lots of code with these intentional OOB accesses and we >> want to >> test it. >> In most cases I've met so far, the developers decided to actually fix the >> bugs >> according to the C++ standard and require the memory allo...

On Fri, Jun 6, 2014 at 10:57 PM, Kostya Serebryany <kcc at google.com> wrote: > As for the deadlocks, indeed it is possible to add deadlock detection > directly to std::mutex and std::spinlock code. > It may even end up being more efficient than a standalone deadlock > detector -- > but only if we can add an extra word to the mutex/spinlock object. > The deadlock

Hi, I am starting to poke at the LLVM JIT, which seems to be in need of some TLC. If you are a "sophisticated" JIT user and are using either internal APIs (either by integrating with LLVM, or by other C++ tricks), or are using obscure or poorly documented public APIs (e.g., why is runJITOnFunction exposed?) please make me aware of it! I reserve the right to break anything which