In 16 years of Go's existence, neither Google nor the community has solved
the race detection problem without CGO. ThreadSanitizer requires
CGO_ENABLED=1,
which makes it unusable for Docker scratch images, cloud functions,
cross-compilation, and embedded systems.
We demonstrated a working concept in pure Go:
- Detector is implemented (FastTrack algorithm, vector clocks, shadow
memory)
- 359/359 tests pass
- Real races are detected
Issue #76786 was not a proposal to merge into upstream. We were gauging
community reaction to see if anyone actually needs this. And we found out
—
yes, they do (rr compatibility, CGO_ENABLED=0, cross-compilation).
The problem is not the detector itself, but the integration. The current
AST-based approach is a proof of concept. With proper Go runtime
integration,
this would work 100% — the compiler already generates
runtime.raceread/racewrite
calls.
About "AI vibe-slop": AI tools are professional force multipliers for
engineers,
not a replacement for expertise. Critics haven't proposed anything
themselves
to solve this 16-year-old problem.
We're actively improving:
- v0.7.1-v0.7.2 fixed issues #15, #16, #17 reported by @glycerine
- Phase 2 will improve instrumentation via go/types and SSA
Related issues:
- #15: Test command flags fix —
https://github.com/kolkov/racedetector/issues/15
- #16: CGO file handling —
https://github.com/kolkov/racedetector/issues/16
- #17: Stack trace display —
https://github.com/kolkov/racedetector/issues/17
- #20: False positives reduction —
https://github.com/kolkov/racedetector/issues/20
Constructive bug reports welcome:
https://github.com/kolkov/racedetector/issues
On Friday, 19 December 2025 at 03:24:36 UTC+3 Jason E. Aten wrote:
> the #performance gopher slack channel pointed to this analysis regarding
> the https://github.com/kolkov/racedetector project:
>
>
> https://old.reddit.com/r/golang/comments/1pjx4hh/proposal_runtimerace_purego_implementation/ntk1k69/
>
> in which hugemang4 starts by saying,
>
> > "While it would be great to have a low-overhead race-detector
> implementation, *this proposal is pure AI vibe-slop*. The race-detector
> implementation they have shared is 100% AI implemented that doesn't even
> work properly. The race-detector implementation they have shared is 100% AI
> implemented that doesn't even work properly. I'm not sure the author has
> even attempt to run the example in the README since it doesn't work as
> `main()` should almost always return before any of the goroutinues even
> begin executing. In fact, this is so broken, that simply unrolling the loop
> causes it to no longer detect the race.
> >
> > "The author claims they pass all of the Go race test, but the first test
> I opened for atomics (
> https://github.com/kolkov/racedetector/blob/main/internal/race/api/go_race_atomic_test.go
>
> ) is incorrect and demonstrates the author doesn't understand concurrent
> memory models enough to implement this correctly. The tests here (
> https://github.com/kolkov/racedetector/blob/main/internal/race/api/go_race_atomic_test.go
>
> ) "simulates" atomic operations by using a mutex, but this is incorrect, as
> the lock acts as a full barrier for surrounding non-atomic operations (the
> `simulateAccess` calls), but in Go (and most other languages) an atomic
> Store only acts as a release barrier and Loads as an acquire barrier. So
> these tests cannot detect a race caused by a load being reordered before a
> prior atomic Store."
>
> Sadly, my own evaluation and filed bug reports tend to confirm that this
> is not a serious implementation of a workable all-Go race detector, but
> indeed, at the moment, can indeed be charitable designated "pure AI vibe
> slop".
>
> I hope that the author can address the problems of the current
> implementation, but that will require alot of manual rather than AI effort.
>
> On Thursday, December 18, 2025 at 8:59:56 PM UTC-3 [email protected]
> wrote:
>
>> https://github.com/golang/go/issues/76786 - Read more about the
>> discussion.
>>
>> On Wednesday, 17 December 2025 at 15:47:12 UTC+3 Jason E. Aten wrote:
>>
>>> This looks amazing. Am to understand that the slowdown under
>>> kolkov/racedetectdor is only 22%, rather than 200-500% slower with the C++
>>> race detector? That is incredible!
>>>
>>> On Friday, November 28, 2025 at 8:07:09 AM UTC-3 [email protected]
>>> wrote:
>>>
>>>>
>>>> 2025 update: This is now possible.
>>>>
>>>> I've built a Pure-Go race detector that works with CGO_ENABLED=0:
>>>> https://github.com/kolkov/racedetector
>>>>
>>>> Works in:
>>>> - Alpine/scratch Docker containers
>>>> - AWS Lambda / Cloud Functions
>>>> - Cross-compilation scenarios
>>>> - Any CGO_ENABLED=0 environment
>>>>
>>>> Usage:
>>>> go install github.com/kolkov/racedetector/cmd/racedetector@latest
>>>> racedetector build -o myapp main.go
>>>>
>>>> It's a standalone tool (not runtime integration yet), but it detects
>>>> races without any CGO dependency. FastTrack algorithm, 15-22% overhead,
>>>> pure Go.
>>>>
>>>> Feedback welcome: https://github.com/kolkov/racedetector/discussions
>>>>
>>>> Best regards!
>>>> On Wednesday, 18 February 2015 at 00:09:22 UTC+3 Blake Caldwell wrote:
>>>>
>>>> I'm building my service without CGO, so ideally, I'd like to run my
>>>> tests with the same settings, and I really like race detection. Is there
>>>> any way to use the race detector with CGO_ENABLED=0?
>>>>
>>>> # testmain
>>>> runtime/race(.text): __libc_malloc: not defined
>>>> runtime/race(.text): getuid: not defined
>>>> runtime/race(.text): pthread_self: not defined
>>>> runtime/race(.text): madvise: not defined
>>>> runtime/race(.text): sleep: not defined
>>>> runtime/race(.text): usleep: not defined
>>>> runtime/race(.text): abort: not defined
>>>> runtime/race(.text): isatty: not defined
>>>> runtime/race(.text): __libc_free: not defined
>>>> runtime/race(.text): getrlimit: not defined
>>>> runtime/race(.text): __libc_stack_end: not defined
>>>> runtime/race(.text): getrlimit: not defined
>>>> runtime/race(.text): setrlimit: not defined
>>>> runtime/race(.text): setrlimit: not defined
>>>> runtime/race(.text): setrlimit: not defined
>>>> runtime/race(.text): exit: not defined
>>>> runtime/race(.text.unlikely): __errno_location: not defined
>>>> runtime/race(.text): undefined: __libc_malloc
>>>> runtime/race(.text): undefined: getuid
>>>> runtime/race(.text): undefined: pthread_self
>>>> runtime/race(.text): undefined: madvise
>>>> too many errors
>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/golang-nuts/ae556c49-7c3d-4633-b676-a2c604c72e5an%40googlegroups.com.
