Open GoogleCodeExporter opened 9 years ago
Hi,
Thanks for the report.
Does QT accept patches from community?
Please also file an issue against QT. Let's see what interest are there.
Original comment by dvyu...@google.com
on 11 Mar 2014 at 6:08
The Qt bug report was closed because it's "not our issue":
https://bugreports.qt.io/browse/QTBUG-37402
However they do accept patches if someone is able to fix the issue in the way
they want you to...
Original comment by cbpar...@gmail.com
on 2 Feb 2015 at 8:37
[deleted comment]
Is there a way to annotate QMutex for ThreadSanitizer to understand it? If so,
then I'd add such code to Qt Base when defined(__has_feature) &&
__has_feature(thread_sanitizer).
If there is no such thing, and I cannot find any headers with macros I could
use for that purpose, can someone point me to the sources in TSan (in
data-race-test, right?) that need to be patched to add support for QMutex?
Original comment by milian.w...@kdab.com
on 16 Jul 2015 at 4:29
Hi milian.wolff,
Yes, tsan supports annotations for mutexes:
https://code.google.com/p/data-race-test/source/browse/trunk/dynamic_annotations
/dynamic_annotations.h
They are implemented in tsan here:
http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/tsan/rtl/tsan_interfac
e_ann.cc?view=markup
In particular you want:
AnnotateRWLockCreate(char *f, int l, uptr m)
AnnotateRWLockDestroy(char *f, int l, uptr m)
AnnotateRWLockAcquired(char *f, int l, uptr m, uptr is_w)
AnnotateRWLockReleased(char *f, int l, uptr m, uptr is_w)
f is file name (__FILE__)
l is line (__LINE__)
m is mutex address
is_w is whether mutexes is locked in write mode or in read mode
AnnotateRWLockAcquired must be called after the actual acquire.
AnnotateRWLockReleased must be called right before the mutex is actually
unlocked.
Original comment by dvyu...@google.com
on 16 Jul 2015 at 8:46
GCC does not seem to support the __has_feature check for TSan - is there an
alternative to detect it there?
Original comment by milian.w...@kdab.com
on 20 Jul 2015 at 10:31
The attached file works fine with clang++, but in GCC it does not work at all.
Note that I rely instead on a define (QT_SANITIZE_THREAD) to be set, instead of
the __has_feature which is also not supported by GCC.
I thought GCC and clang share the same TSan, but this here shows that
apparently this is it not the case. Is there any way to fix this also for GCC?
Original comment by milian.w...@kdab.com
on 20 Jul 2015 at 12:53
Internally at Google we define THREAD_SANITIZER macro when tsan is enabled, and
check that macro.
You can file a bug against gcc, but as far as I remember they intentionally did
not implement it.
Original comment by dvyu...@google.com
on 20 Jul 2015 at 6:09
Yuri, do you know any way to detect if a sanitizer is enabled or not in gcc?
Original comment by dvyu...@google.com
on 20 Jul 2015 at 6:10
OK, I can add a similar macro. But the annotations don't work there - should
they? I'm using GCC 5.1.0.
Original comment by milian.w...@kdab.com
on 21 Jul 2015 at 2:26
gcc should support these annotations as well.
Please show how you annotate, and how exactly annotation don't work (don't
compile? don't link?).
Original comment by dvyu...@google.com
on 22 Jul 2015 at 6:25
Adding Project:ThreadSanitizer as part of GitHub migration.
Original comment by gli...@google.com
on 30 Jul 2015 at 9:21
Original issue reported on code.google.com by
benjamin...@wincor-nixdorf.com
on 10 Mar 2014 at 1:10