What are the regexp and input that caused this?

I will email them to you but it shouldn't matter. It's b.cap[0] being written to. That's the overall match. And as I said, the obvious 1-line use of them doesn't crash.

Ok. How can I reproduce the panic? What program was the example contained in?

Instead of trying to reproduce it, let's look at what's already been reported. b.cap[0] = pos is being executed and failing because len(b.cap) is apparently 0. Why is it okay to write to b.cap[0] on that line? It looks to me like in the stack trace the argument reqcap passed to backtrack is 0.

This may duplicate #10316. A possible patch is here: https://go-review.googlesource.com/#/c/8473/1/src/regexp/exec.go

I think these are separate issues.

When porting the backtracking code, I made the assumption that len(m.matchcap) is always >= 2. Then b.cap would be initialized (via the call to b.reset) to have at least length len(m.matchcap), so accesses to b.cap[0] and b.cap[1] would always be valid. And that assumption is true whenever a machine only runs the backtracker because when a machine is initalized in progMachine, its minimum length is set to 2. However, when the standard matcher is used, m.matchcap is resliced (in m.init) to ncap which may have length less than 2. So if the backtracker is run after the standard matcher on the same machine and no captures are requested the assumption won't hold.

So the backtracking code can either check for reqcap when setting b.cap[0] or b.cap[1], or initalize b.cap to have length at least 2.

Please send a CL fixing this. I would check reqcap. There's no point filling out b.cap[0] if it's not needed.

Sorry, it seems I tagged the wrong issue in a513088. That closed #10316, but @michaelmatloob points out this is a different issue

Here's a reproducer using tip: http://play.golang.org/p/xxYClfmmjK. Hope that helps. Sorry about the size and noise in it. Too distracted by other things to minimize at the moment.