I can't see how that line could be unlocking an unlocked map. It is dominated by the lock call.

Any chance you're copying the Map? That might explain your crash.

A Map must not be copied after first use.

Is there any way you can share the code so we can reproduce this crash?

Hi, @randall77

i am aware of the copying map issue, and i confirm we are not copying the map.

i will provide a mock code

package shared

import "sync"

type Stats struct {
	items sync.Map
}

type item struct {
	Id    string  `json:"id"`
	Value float64 `json:"value"`
}

func NewStats() *Stats {
	instance := Stats{}
	instance.items = sync.Map{}
	return &Stats{}
}

func (ss *Stats) Add(key string, value item) {
	ss.items.Store(key, value)
}

func (ss *Stats) Flush() {
	ss.items = sync.Map{}
}

what we do is during start up, we create an instance and make it available globally

global.StatsManager := NewStats()

and we have a ticker that is called every 10minutes (we collect data and adapat/store in elasticSearch)
Once done, we call the Flush Method the re initiate.

we do not copy the instance,

Unless the Flush() method is the issue ?

what are doing is trying to restart over once data is on elastic search,

Yes, I think Flush is the issue. If there are outstanding map operations currently in progress on global.StatsManager.items, you can't do global.StatsManager.items = sync.Map{}. Although technically that doesn't violate the rule "don't copy a map before first use" because the map you're copying hasn't been used yet. But you're copying onto an in-use Map, which is also bad. It may be worth adding something to the doc, although it seems pretty obvious that's unsafe if you think about it long enough. @bcmills

Speaking of which, the race detector should have caught this bug. Have you tried running with the race detector on?

It may be worth adding something to the doc, although it seems pretty obvious that's unsafe if you think about it long enough.

We have a test that sync.Map triggers the vet copylock check. If go vet didn't catch the assignment, that's arguably a bug in vet.

When i run a go vet nothing is reported,

And this is very random, and very hard to reproduce, but in production it happens many times a day.

i will try to improve the Flush() method and see how this can help.

@bcmills I think the vet copylock check isn't triggered when the RHS is a composite literal. Presumably because copying a zero lock is allowed.
It's the overwriting that's the problem here, not the copying itself.

@amezghal - Do you get any errors under the race detector ?

Once i have updated the Refresh method i no longer get this error,

Ok, I'll close this issue then.
(Is Refresh the same as Flush?)

Yes Flush
re init the sync.Map while it was being excessively updated without synchronisation from other go-routines was the issue.

@davecheney
I restored the old code and run it with the -race,

yes the racedetector is reporting the data race,

thks