Hello Jason, Intuitively, to play with timing of goroutines, *to manually inject delays where none exists,* is what new comers do, to experiment with deadlocks, or simply build better understanding, at least *I* did that very often. Therefor your suggestion definitely makes sense, to me, a *non* low level programmer perspective.
(*not a useful email*, i only want to show some support to your various posts which i read with lots of interest, others too... but physically speaking it is hard to follow everybody, I liked the last post from Robert Griesemer I like all the post of the Go blog anyway...... and the coroutines.... *c'est interminable*...= ) Thank you, Thank you all. Le jeudi 5 juin 2025 à 22:28:07 UTC+2, Jason E. Aten a écrit : > Hmm. Maybe rr found a bug in runtime GC code(?)... or > maybe it will be hard to use rr on Go. Let's see what the runtime folks say > on this issue: > > https://github.com/golang/go/issues/74019 > > On Wednesday, June 4, 2025 at 12:18:45 PM UTC+1 Jason E. Aten wrote: > >> This is a fascinating approach to finding hard to >> reproduce event-interleaving related bugs. >> >> I'm particularly interested in this approach >> because rr record and replay plus chaos >> mode is directly applicable to >> Go programs -- whereas deterministic simulation >> testing (DST) is next to impossible in a Go program >> using more than 4GB of memory (like most of my >> programs) because this rules out wasm. >> >> In contrast to DST, the rr+chaos approach >> accepts you will be randomly >> sampling executions, but by recording all of them you >> can still get reproducibility when you do hit the issue. >> >> rr is very efficient at recording. Green test runs can be quickly >> discarded. >> >> In a blog from 2016, Robert O'Callahan, one of the principal rr authors, >> talks about the design of rr's chaos mode for provoking hard to find >> concurrency bugs: >> >> > To cut a long story short, here's an approach that works. >> > Use just two thread priorities, "high" and "low". Make >> > most threads high-priority; I give each thread a 0.1 >> > probability of being low priority. Periodically re-randomize >> > thread priorities. Randomize timeslice lengths. >> > >> > Here's the good part: periodically choose a short random interval, >> > up to a few seconds long, and during that interval do not >> > allow low-priority threads to run at all, even if they're >> > the only runnable threads. Since these intervals can >> > prevent all forward progress (no control of priority inversion), >> > limit their length to no more than 20% of total run time. >> > >> > The intuition is that many of our intermittent test failures >> > depend on CPU starvation (e.g. a machine temporarily >> > hanging), so we're emulating intense starvation of a few >> > "victim" threads, and allowing high-priority threads to >> > wait for timeouts or input from the environment >> > without interruption. >> > >> > With this approach, rr can reproduce my bug >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1213938> in >> > several runs out of a thousand. I've also been able >> > to reproduce a top intermittent >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1237176> (now being fixed), >> > an intermittent test failure >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1203417> that was assigned >> to me, >> > and an intermittent shutdown hang in IndexedDB >> <https://bugzilla.mozilla.org/show_bug.cgi?id=1150737#c197> >> > we've been chasing for a while. A couple of other >> > people have found this enabled reproducing their >> > bugs. I'm sure there are still bugs this approach >> > can't reproduce, but it's good progress. >> > >> > I just landed all this work on rr master. The >> > normal scheduler doesn't do this randomization, >> > because it reduces throughput, i.e. slows down >> > recording for easy-to-reproduce bugs. >> > Run rr record -h to enable chaos mode for >> > hard-to-reproduce bugs. >> -- https://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html >> >> Links to more info and background on rr: >> >> https://rr-project.org/ >> https://github.com/rr-debugger/rr >> https://github.com/rr-debugger/rr/wiki/Usage >> https://github.com/rr-debugger/rr/wiki/Testimonials >> https://github.com/rr-debugger/rr/wiki/Building-And-Installing >> >> https://arxiv.org/pdf/1705.05937 >> >> https://fitzgen.com/2015/11/02/back-to-the-futurre.html >> >> >> https://www.percona.com/blog/replay-the-execution-of-mysql-with-rr-record-and-replay/ >> https://www.youtube.com/watch?v=61kD3x4Pu8I >> >> Robert's talk, "Taming Non-determinism" from 9 years ago is >> a good technical introduction to rr. >> https://www.youtube.com/watch?v=H4iNuufAe_8 >> >> NB The Delve debugger for Go supports rr, so you can get goroutine stack >> traces. >> >> Enjoy. >> >> - Jason >> > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/23ea9941-43ea-48aa-ba30-f592bafb6a5dn%40googlegroups.com.
