Live data from Hacker News

What if we could see all concurrency bugs in the debugger?

stefan-marr.de

11–20 of 28 posts

Re: What if we could see all concurrency bugs in the debugger?

#11
The interface looks pretty interesting!

I think adding a way to select multiple universe nodes and say “I expect all these universes to converge on the value 66” and then serialize that expectation into a runtime verification which either runs during program execution or runs during program execution when in a concurrency sanitize mode would be pretty cool!

Re: What if we could see all concurrency bugs in the debugger?

#12
post #3

Earlier quoted context omitted.

Mozilla's rr is made for exactly that.

WinDBG's Time-Travel Debugging is another nice implementation of this.

Heh, it feels like everybody and their dog has written a reversible debugger.

Listed in this Hacker News thread we have 7 implementations in gdb, plus rr and WinDBG.

I'll add one more, an in-house hypervisor that I help develop. Stuff like finding "all concurrency bugs" as in this article would be a matter of scripting it up. BTW, we're hiring: https://news.ycombinator.com/item?id=19797601

So that's at least 10, counting the gdb backends distinctly except lumping the Linux native x86 and x86_64 together.

Re: What if we could see all concurrency bugs in the debugger?

#13
post #5

Reminds 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, differe…

I think the typical business software could be a great place to start because you have sections of the code that would be very simple to model in a formal methods environment and that really hairy section that could actually use it (but it would be hard).

I hate to say I've never had the patience for it. For me it has always turned out to be painful without much reward.

I think my experience isn't uncommon given the popularity of formal methods. If it was easy and full of low hanging fruit (like automated testing) it would probably be reasonably popular (like automated testing).

Re: What if we could see all concurrency bugs in the debugger?

#15
post #13

Earlier quoted context omitted.

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, differe…

I think the typical business software could be a great place to start because you have sections of the code that would be very simple to model in a formal methods environment and that really hairy section that could actually use it (but it would be hard). I hate to say I've never had the patience for it. For me it has always turned out to be painful without much reward. I think my experience isn't uncommon given the…

I dunno where in business software it might work, but my experience is that quality is often almost irrelevant. A few weeks ago I got myself unpopular for finding and reporting a serious bug. That could have been picked up through a little knowledge or some straightforward testing, but it wasn't because that didn't happen (there's a little more to it than that, but you see my point). If producing crap is acceptable, there's no room for formal methods. I've had a lot of experience of this.

If you can't get the boss's buy-in for even obvious correctness and/or timesaving approaches (where time spent = salaries paid), I'm stuffed.

Or maybe the problem's partly me. I can't rule that out. I'm not the most politic person.

> If [formal methods] was easy and full of low hanging fruit...

It isn't and I don't expect it to be. The fruit is right at the top, but it may be the best quality. I'm ok putting in the work to reach that.

Re: What if we could see all concurrency bugs in the debugger?

#16
post #8

TLA+ 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.

TLA+ is great, but it struggles so much to handle lots of states...

Maybe that's a good thing since it encourages very symmetric designs, but it bothers me

Re: What if we could see all concurrency bugs in the debugger?

#18

The interface looks pretty interesting! I think adding a way to select multiple universe nodes and say “I expect all these universes to converge on the value 66” and then serialize that expectation into a runtime verification which either runs during program execution or runs during program execution when in a concurrency sanitize mode would be pretty cool!

Thanks for the suggestion we don’t provide that exact interface but we do allow querying over all the universes with a graph query language. In the paper we detail how to get the shortest path to all the end states which makes it a bit easier to debug.

Re: What if we could see all concurrency bugs in the debugger?

#19
post #8

TLA+ 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.

TLA+ is great, but it struggles so much to handle lots of states... Maybe that's a good thing since it encourages very symmetric designs, but it bothers me

Are there other systems where combinatorial explosions of states do not occur? Is there something in TLA that makes it prone to this where other model checkers perhaps aren't? Slightly related, isn't state space explosion an intrinsic part of any such problem?

If possible, could you explain what you mean by symmetry, and how it reduces state space (it's a big ask, I know).

sorry for the firehose of Q's! I'd really appreciate an expert's view though.

Re: What if we could see all concurrency bugs in the debugger?

#20

Earlier quoted context omitted.

TLA+ is great, but it struggles so much to handle lots of states... Maybe that's a good thing since it encourages very symmetric designs, but it bothers me

Are there other systems where combinatorial explosions of states do not occur? Is there something in TLA that makes it prone to this where other model checkers perhaps aren't? Slightly related, isn't state space explosion an intrinsic part of any such problem? If possible, could you explain what you mean by symmetry, and how it reduces state space (it's a big ask, I know). sorry for the firehose of Q's! I'd really ap…

Model checkers are essentially glorified fuzzers, so the way they work is inherently vulnerable to state space explosion. The way to address that is to move closer to building things that are correct "by construction", and prove them as such. Symmetry is one way of doing this, it allows you to "reduce" a whole lot of redundant checking to something much simpler, based on some underlying properties of what you're working with. A logical proof works much the same way, of course.

TLA specifications are typically "checked", or rather "fuzzed" by model checkers; this is not formally required (TLA+ even includes a proof language) but things tend to be done that way.

Post reply on HN