What if we could see all concurrency bugs in the debugger?
1–10 of 28 posts
Re: What if we could see all concurrency bugs in the debugger?
#2Not quite the same, but reminded me of reversible debugging: https://www.gnu.org/software/gdb/news/reversible.html
Re: What if we could see all concurrency bugs in the debugger?
#3Not quite the same, but reminded me of reversible debugging: https://www.gnu.org/software/gdb/news/reversible.html
Mozilla's rr is made for exactly that.
Re: What if we could see all concurrency bugs in the debugger?
#4Obligatory plug for LLVM’s Thread Sanitizer, which can find many concurrency issues before their express themselves as difficult-to-debug problems.
Re: What if we could see all concurrency bugs in the debugger?
#5Reminds me of Corensic's Jynx.
https://en.wikipedia.org/wiki/Jinx_Debugger
Never used it but the premise of running different possible thread interleavings in parallel and picking the one that crashes seemed genius.
Re: What if we could see all concurrency bugs in the debugger?
#6For property-based testing of concurrency & nondeterminism, look into dejafu :)
Re: What if we could see all concurrency bugs in the debugger?
#7Re: What if we could see all concurrency bugs in the debugger?
#8TLA+ specs explore all state spaces of concurrent processes. Avoiding state explosions is something you need to be conscious of when building those. The modeling required also takes some learning investment. Curious if this can really pull off something like a TLA+ state exploration and invariant violation detection with real-world code.
Re: What if we could see all concurrency bugs in the debugger?
#9Reminds me of Corensic's Jynx. https://en.wikipedia.org/wiki/Jinx_Debugger Never used it but the premise of running different possible thread interleavings in parallel and picking the one that crashes seemed genius.
Sounds like what some model checkers do. See https://en.wikipedia.org/wiki/SPIN_model_checker for example.
Spin homepage http://spinroot.com/spin/whatispin.html
SPIN's language Promela is very odd, like stripped down basic from the 1980s but even more reduced after that.
Edit: a bit more from the spin site FYI "[spin] checks the logical consistency of a specification and reports on deadlocks, race conditions, different types of incompleteness, and unwarranted assumptions about the relative speeds of processes"
I wish so much I had reason to use it. I so much wish my programming career wasn't the daily, usually boring, straightforward business support. I'd love to work with TLA, formal methods, this and more but there seems no way to do get a job doing this. Any thoughts welcome. Been trying to learn hoare logic but it all seems so abstract, and it's easy to misunderstand things with no-one to ask. Anyway, sorry for the whinge.
Re: What if we could see all concurrency bugs in the debugger?
#10Reminds me of super-compilation.