After having been assigned to a nil value at memmap.go:240, pointer '&parent.Mutex' is passed as implicit 'this' parameter in call to function 'sync.Mutex.Lock' at memmap.go:131, where it is dereferenced at mutex.go:16.
After having been assigned to a nil value at memmap.go:240, pointer 'f' is passed as 1st parameter in call to function 'afero.MemMapFs.findParent' at memmap.go:73, where it is dereferenced at memmap.go:85.
It's looks like false positive because an error returns on line 240 that is being handled in methods registerWithParent and unRegisterWithParent. But there is a moment. getData() returns a map that stores pointers and there is no check for getting nil by existed keys in methods lockfreeOpen and open. This potentially may causes panics.
Please add checks for getting nil where they need to be.
About
v.1.11.0.Static analysis shows two critical:
It's looks like false positive because an error returns on line 240 that is being handled in methods
registerWithParentandunRegisterWithParent. But there is a moment.getData()returns a map that stores pointers and there is no check for gettingnilby existed keys in methodslockfreeOpenandopen. This potentially may causes panics.Please add checks for getting
nilwhere they need to be.