Yes, the agent is sometimes in a hurry, it happens. But that doesn't mean I, as an engineer, forget about it or don't attach importance to it. We're working tirelessly to find a solution, and it seems we've already found it... https://github.com/kolkov/racedetector/issues/25
On Friday, 19 December 2025 at 05:15:41 UTC+3 Jason E. Aten wrote: > Anyone can close an issue without actually fixing it. AI are very good at > that. And its not an advantage. > > That has happened twice now on > https://github.com/kolkov/racedetector/issues/17, which I file, > and which is still not fixed after two AI attempts and auto closing it. > > Its not worth wasting more of my time on such projects. > > On Thursday, December 18, 2025 at 10:03:20 PM UTC-3 [email protected] > wrote: > >> 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/a3ab08c7-9c5d-4318-9c6f-f595d5711526n%40googlegroups.com.
