去json编组员惊慌失措，“在零值上调用 reflect.Value.Int”

Question

我正在尝试在具有多级嵌套的复杂结构中取消封送一些数据（因此，此处不复制该结构）。然而，当代码上线时，我们开始在极少数情况下出现以下恐慌（难以量化，但可能是1000例中的1例）。以下是该问题的堆栈跟踪：panic: reflect: call of reflect.Value.Int on zero Value [recovered]        panic: reflect: call of reflect.Value.Int on zero Value    goroutine 568428 [running]:    encoding/json.(*encodeState).marshal.func1(0xc0081d5c70)            /usr/local/go/src/encoding/json/encode.go:305 +0x9a    panic(0x13968c0, 0xc005c2f540)            /usr/local/go/src/runtime/panic.go:679 +0x1b2    reflect.Value.Int(...)            /usr/local/go/src/reflect/value.go:986    encoding/json.intEncoder(0xc0074b5dc0, 0x0, 0x0, 0x0, 0xc0038b0100)            /usr/local/go/src/encoding/json/encode.go:522 +0x1d4    encoding/json.mapEncoder.encode(0x1608760, 0xc0074b5dc0, 0x1385c20, 0xc00119f5e0, 0x195, 0x100)            /usr/local/go/src/encoding/json/encode.go:706 +0x351    encoding/json.structEncoder.encode(0xc0002ce600, 0x19, 0x21, 0xc00027ede0, 0xc0074b5dc0, 0x156c820, 0xc00119f510, 0x199, 0x520100)            /usr/local/go/src/encoding/json/encode.go:664 +0x306    encoding/json.ptrEncoder.encode(0xc00027ee10, 0xc0074b5dc0, 0x1397e80, 0xc00119f510, 0x16, 0x1390100)            /usr/local/go/src/encoding/json/encode.go:810 +0xb1    encoding/json.(*encodeState).reflectValue(0xc0074b5dc0, 0x1397e80, 0xc00119f510, 0x16, 0x100)            /usr/local/go/src/encoding/json/encode.go:337 +0x82    encoding/json.(*encodeState).marshal(0xc0074b5dc0, 0x1397e80, 0xc00119f510, 0xc003da0100, 0x0, 0x0)            /usr/local/go/src/encoding/json/encode.go:309 +0x10b    encoding/json.Marshal(0x1397e80, 0xc00119f510, 0x40be53, 0x13c4160, 0x1397e80, 0x1, 0x7fa9d5d348b0)            /usr/local/go/src/encoding/json/encode.go:161 +0x52    reingames.com/rm/user.(*userCore).MarshalBinary(0xc00119f510, 0x1397e80, 0xc00119f510, 0x7fa9d5d348b0, 0xc00119f510, 0x1)            /home/shivam/goprojects/rmgs/go/user/profile.go:180 +0x37我不知道从哪里开始调试它。有没有人经历过类似的事情？快速问题 - 争用条件（在更新指针时对其进行编组）是否会导致这种恐慌？

Answer 1

开始调试的一种方法是 ：使用指令捕获 panic，并记录有关错误上下文的信息。recover()

这不会“在行为中”捕获竞争条件，但它肯定会帮助您了解有关错误的更多信息（它是否总是发生在相同的元素上？元素是否仍处于有效状态？等等......）

Answer 2

是的，一场比赛几乎可以造成任何事情，包括这个。如果您有任何测试要说，请使用 运行它们。如果没有，或者如果这没有显示任何内容，则可以考虑使用 进行金丝雀构建，但请参阅竞赛检测器文档，了解有关在这种情况下的性能和内存使用情况的注意事项。您可能只想自己检查代码中的种族。go test -racego build -race




Answer 3

最近我们还遇到了这个问题，可以检查一下代码中是否是协程，有没有合适的切片操作。切片依赖于数组实现。当基础数组具有足够的容量时，追加操作不是只读操作，而是将元素直接添加到数组的可用位置。因此，当多协程对全局切片执行追加操作时，它将对相同的基础数据进行操作，从而导致读写冲突。导致 Go json 编组程序的异常。