20220314线上panic总结

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x9273ea]

goroutine 106262 [running]:
github.com/antlinker/alog/store.(*FileStore).fileName.func1({0xc0093dd920, 0x23}, {0x0, 0x0}, {0xc000e7de70, 0x0})
	/Users/liuyong/go/pkg/mod/github.com/antlinker/alog@v1.0.0/store/file.go:82 +0x4a
path/filepath.walk({0xc00440d308, 0x15}, {0x10b0bf0, 0xc00406dc70}, 0xc000e7de70)
	/usr/local/go/src/path/filepath/path.go:438 +0x20d
path/filepath.walk({0xc000440530, 0x9}, {0x10b0bf0, 0xc00403ef70}, 0xc000e7de70)
	/usr/local/go/src/path/filepath/path.go:442 +0x28f
path/filepath.Walk({0xc000440530, 0x9}, 0xc000e7de70)
	/usr/local/go/src/path/filepath/path.go:505 +0x6c
github.com/antlinker/alog/store.(*FileStore).fileName(0xc0001a6160, 0x0)
	/Users/liuyong/go/pkg/mod/github.com/antlinker/alog@v1.0.0/store/file.go:81 +0x1ef
github.com/antlinker/alog/store.(*FileStore).Store(0xc0001a6160, 0x0)
	/Users/liuyong/go/pkg/mod/github.com/antlinker/alog@v1.0.0/store/file.go:129 +0x65
github.com/antlinker/alog/manage.(*_LogManage).writeStore(0xc0001161e0, 0x108ad10, {0xc0004404e0, 0xc0043f5278}, 0xc0000cee98)
	/Users/liuyong/go/pkg/mod/github.com/antlinker/alog@v1.0.0/manage/manage.go:325 +0x93
created by github.com/antlinker/alog/manage.(*_LogManage).store
	/Users/liuyong/go/pkg/mod/github.com/antlinker/alog@v1.0.0/manage/manage.go:268 +0xbf

初看panic很容易根据堆栈问题追踪到panic出错的代码是第三方的日志包引起的。追踪到源码很容易看到如下代码。

filepath.Walk(root, func(path string, info os.FileInfo, err error) error {
		if info.IsDir() || !strings.HasPrefix(path, prefix) {
			return nil
		}
		filterFile = append(filterFile, info)
		return nil
	})

初看起来好像是没有问题， 但是仔细一看这是调用go源码包的filepath.Walk方法。 第二个参数是闭包函数。
闭包调用时传递进来一个error此时很容易看到这个error是没有处理的。
这时我们来看看go源码里面的调用。

func Walk(root string, fn WalkFunc) error {
	info, err := os.Lstat(root)
	if err != nil {
		err = fn(root, nil, err)
	} else {
		err = walk(root, info, fn)
	}
	if err == SkipDir {
		return nil
	}
	return err
}

我们可以发现这一行代码

err = fn(root, nil, err)

出错的时候传递了一个nil进去。所以我们很容易知道第三方包的调用时 info os.FileInfo 这个参数传递进来会是个nil。
此时因为没有判断错误，直接就使用了这个nil接口类型调用方法，很明显是会报空指针异常的，进而导致了panic错误。
从这个例子中也很明显的警告我们如果使用第三方包的话最好使用一些稳定的，得到大多数人认可的。当然如果是团队规模
很大的话，应该是会对任何第三包引用的代码都需要review的。
其实最最主要的是通过这个例子告诉我们，任何时候都不应该随便的忽略错误进行处理，尤其是当你使用应用方法返回或传递进来的除了error以外的参数。