Wed, Dec 14, 2022 at 10:21:10AM +0100, Klaus Schmidinger wrote:
Is there an actual problem that requires this?
It has been that way for many, many years, so I'd like to see more than
"looks problematic to me" before I dare touch this ;-).
The only problem that I am currently aware of is
On 10.12.22 18:30, Marko Mäkelä wrote:
...
Finally, I figured out what is causing the first report: cThread::description
is not protected by cThread::mutex. Possibly, most cThread data members
(including cThread::active) should be protected by cThread::mutex?
Unless I'm missing something,
Sat, Dec 10, 2022 at 07:30:50PM +0200, Marko Mäkelä wrote:
Because of the heap-use-after-free race condition that was rather
easily reproducible with AddressSanitizer (-fsanitize=address), I
thought that I should finally try to learn to use ThreadSanitizer
(TSAN, -fsanitize=thread in GCC and
Sat, Dec 10, 2022 at 07:30:50PM +0200, Marko Mäkelä wrote:
Finally, I figured out what is causing the first report:
cThread::description is not protected by cThread::mutex.
Sorry, I failed to notice that even after applying both patches, both
TSAN reports are still there. The race condition
Because of the heap-use-after-free race condition that was rather easily
reproducible with AddressSanitizer (-fsanitize=address), I thought that
I should finally try to learn to use ThreadSanitizer (TSAN,
-fsanitize=thread in GCC and clang).
https://clang.llvm.org/docs/ThreadSanitizer.html
