Please provide some way that we can reproduce this issue.

Missing reproducer aside, the stack trace seems to indicate the error really originates from within sync.Map code itself.

Alerting @bcmills too

@davecheney sorry, as it's used in a private project, I could share the details on how to reproduce it.

@zjshen14 how often does it occur in your project?

If I provide a hypothetical close reproducer, could you please help me provide edits to help get the reproducer to cause the concurrent read+write fatality? How is this for a start? https://play.golang.org/p/Odxo5TIUL4S or inlined.

package main

import (
	"context"
	"sync"
	"time"
)

func main() {
	m := new(sync.Map)
	key := "foo"

	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	tick := time.NewTicker(1e3)
	// Writer routine
	go func() {
		i := 0
		for {
			m.Store(key, i)
			i += 1

			select {
			case <-tick.C:
				// Continue
			case <-ctx.Done():
				return
			}
		}
	}()

	// Delete routine
	go func() {
		i := 0
		for {
			m.Delete(key)
			i += 1

			select {
			case <-tick.C:
				// Continue
			case <-ctx.Done():
				return
			}
		}
	}()

	// Get routine for unexpungement
	go func() {
		i := 0
		for {
			m.Load(key)
			i += 1
			select {
			case <-tick.C:
				// Continue
			case <-ctx.Done():
				return
			}
		}
	}()

	for i := 0; i < 1e9; i++ {
		m.Range(func(key, value interface{}) bool {
			return true
		})
	}
}

This looks like memory corruption. Have you tried running your program under the race detector? See https://blog.golang.org/race-detector .

Even if it is a bug in sync.Map (which is possible, but I hope unlikely), the race detector should make it much easier to diagnose.

I met similar problems too, when use sync.(*Map).Range, panic occurs，

fatal error:concurrent map iteration and map write

and i use Go Race Detector, find no warning

@barryqiu can you please open a new issue following the issue template. Thank you.

@barryqiu, can you provide an example program that reproduces the crash? Without either that or a race detector report, we don't have much to go on.

This is coming out in production environments, occasionally, hard to reproduces

If your test coverage is it able to provoke the issue, are you able to build a version of your application with the race detector enabled and deploy it to a percentage of servers In your fleet.

statck as follows
`runtime.throw(0x93ee2f, 0x26)
/data/barry_dev/go/src/runtime/panic.go:605 +0x95 fp=0xc4390d0a10 sp=0xc4390d09f0 pc=0x42ed95

runtime.mapiternext(0xc4390d0b10)
/data/barry_dev/go/src/runtime/hashmap.go:778 +0x6f1 fp=0xc4390d0aa8 sp=0xc4390d0a10 pc=0x40d441

sync.(*Map).Range(0xc44840ff50, 0xc4390d0bd8)
/data/barry_dev/go/src/sync/map.go:331 +0xf8 fp=0xc4390d0b80 sp=0xc4390d0aa8 pc=0x474a58`

If your test coverage is it able to provoke the issue, are you able to build a version of your application with the race detector enabled and deploy it to a percentage of servers In your fleet.

I will try

Can you please post the entire stack panic message including the entire set of stack traces.

one goroutine Store value in the sync.Map and another goroutine Range the sync.Map, and I got the panic

Without a way to reproduce this issue locally I wrote up a quick stress test of sync.Map to try to provoke a panic.

https://play.golang.org/p/PVpk6SvnLzq

So far I have not been able to.

@barryqiu @zjshen14 i'm sorry you are having issues, but without an assertion that your code bases are free of data races, or a code sample that reproduces the issue, it is hard to make progress on resolving this issue.

1. This is not a regression introduced in Go 1.10, because the stack trace posted by @barryqiu is produced by Go 1.9.

2. I read the code of sync.Map and I think this can't be a bug in it.

@barryqiu @zjshen14 Are you sure your code doesn't copy the sync.Map after first use?
I can reproduce the identical stack trace if I copy sync.Map.
The code is

package main

import (
	"math/rand"
	"sync"
)

func main() {
	var m sync.Map

	for i := 0; i < 64; i++ {
		key := rand.Intn(128)
		m.Store(key, key)
	}
	n := m
	go func() {
		for {
			key := rand.Intn(128)
			m.Store(key, key)
		}
	}()
	for {
		n.Range(func(key, value interface{}) bool {
			return key == value
		})
	}
}

@crvv u r right, I copy the sync.map, I have this panicn in both golang 1.10 and golang 1.9. so why the copy will lead to this panic occasionally?

The document says "A Map must not be copied after first use"
https://golang.org/pkg/sync/#Map
Actually, everything in sync and sync/atomic must not be copied after first use.

After copying the sync.Map, two sync.Maps are holding the same map.
Two goroutines can access this map without protection of one mutex.

Looks like we can close here. Thanks @crvv for the investigative work : )

Would some sort of copy detection help here? Have the sync.Map store the address on first use and clearly panic if it changes?

Would some sort of copy detection help here?

The vet copylocks check already catches it (https://golang.org/cl/59690). I do not know why the copylocks check was not enabled by default as part of #18085.

It's commented out in a TODO(@rsc) here:

It's nice that we now run go vet automatically, but I really, really wish it was more obvious in the release notes that not all checks are enabled by default

https://golang.org/doc/go1.10#introduction

The mention here is not enough: apparently many people don't read the entire document, as I've discovered myself by finding this issue resident in living codebases.

copylock has false positive. I think this is the reason.
#13675