svn commit: r335171 - head/sys/vm

[Konstantin Belousov]

On Mon, Jun 25, 2018 at 06:30:20AM -0400, Mark Johnston wrote:
> On Fri, Jun 15, 2018 at 02:03:03PM +0300, Konstantin Belousov wrote:
> > On Fri, Jun 15, 2018 at 11:03:06AM +0100, Steven Hartland wrote:
> > > On 15/06/2018 00:07, Alan Cox wrote:
> > > >
> > > >> On Jun 14, 2018, at 5:54 PM, Steven Hartland 
> > > >> <steven.hartland at multiplay.co.uk 
> > > >> <mailto:steven.hartland at multiplay.co.uk>> wrote:
> > > >>
> > > >> Out of interest, how would this exhibit itself?
> > > >>
> > > >
> > > > A panic in vm_page_insert_after().
> > > >
> > > So just to confirm this couldn't cause random memory corruption of the 
> > > parent process?
> > 
> > No, or to put it more sincere, I highly doubt it.
> > 
> > Also, I do not think that this Go issue will be solved serendipitously
> > by some FreeBSD bug fix.  So far it is indicative that either the
> > situation is too unique for the Go runtime so it is not exposed by other
> > programs (which is quite doubtful), or this is a bug in Go runtime.
> > 
> > The only way forward is to understand what exactly is broken for the
> > situation.  This requires at least deep knowledge the Go garbage collector
> > internal working, which itself supposes understanding of the Go runtime
> > and Go environment.  I do not mean explanation of the assert, but the
> > root cause that eventually triggers the assert.  They are somewhat
> > disjoint in time, I believe.
> 
> Is this problem summarized anywhere?  In particular, is there a
> reasonably minimal test case that reproduces the problem?
Go bug report has the reproducer.  I do not remember if this is the
same snippet that I used.
https://github.com/golang/go/issues/15658

When I looked at it, it took tens of minutes to trigger on sandy bridge
machine.  Note that recent reporters indicate that they need to run the
test for a whole day.  It might be that there are more then one issues,
and some of them are fixed.