Closed stupidjohn closed 2 years ago
do you have the full example?
do you have the full example?
ok, it's really simple
units = make(map[int32]*gdd.PveUnitCsv)
var list []*gdd.PveUnitCsv= gdd.G.GetPveTroop(troopCfg.Troops)
for _, u := range list {
units[u.UnitId] = u
}
the map is make and insert in getNpcUniCfgBuff
func, and return from it.
I think we're going to need a runnable example that demonstrates the problem if we're going to be able to fix it.
Does this happen all the time, or only occasionally?
Does running with the race detector (-race
) report anything?
Does your program use unsafe
anywhere?
I think we're going to need a runnable example that demonstrates the problem if we're going to be able to fix it.
Does this happen all the time, or only occasionally?
Does running with the race detector (
-race
) report anything?Does your program use
unsafe
anywhere?
hi, randall77. could you please explain how a data race could lead to allocator memory corruption? i could use the knowledge to troubleshoot the bug. im afraid i could not offer a complete runable program to you, and we use no unsafe/unintptr in our code(except some lib like gogoprotobuf, uber zap etc).
hi, randall77. could you please explain how a data race could lead to allocator memory corruption? i could use the knowledge to troubleshoot the bug.
If your program has a data race, then all bets are off for the runtime executing your program correctly. Data races can lead to the breaking of type safety (due to races on interface writes, among others), and that can lead to overwriting memory, including runtime data structures, which can lead to arbitrary crashes.
But of course the first thing to do is just run your program with -race
and see what happens.
How about the other questions I asked?
hi, randall77. could you please explain how a data race could lead to allocator memory corruption? i could use the knowledge to troubleshoot the bug.
If your program has a data race, then all bets are off for the runtime executing your program correctly. Data races can lead to the breaking of type safety (due to races on interface writes, among others), and that can lead to overwriting memory, including runtime data structures, which can lead to arbitrary crashes.
But of course the first thing to do is just run your program with
-race
and see what happens.How about the other questions I asked?
thank for give reference, we will check our code by this doc. if we cannot find & fix problem by ourself, we will take log here.
thanks for attention
Timed out in state WaitingForInfo. Closing.
(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (
go env
)?go env
OutputGO111MODULE="off" GOARCH="amd64" GOBIN="" GOCACHE="/home/zhuoyikang/.cache/go-build" GOENV="/home/zhuoyikang/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/zhuoyikang/Go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/zhuoyikang/Go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/home/zhuoyikang/GoSDK/go1.15.6" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/home/zhuoyikang/GoSDK/go1.15.6/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build665856385=/tmp/go-build -gno-record-gcc-switches"
What did you do?
we make a map by units = make(map[int32]*Struct), and then insert it, golang panic out with "span has no free objects". looks like mcentral give a full span when it should give a partial full one.
What did you expect to see?
program run with no problem.
What did you see instead?
panic with