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
registerWithParent
andunRegisterWithParent
. But there is a moment.getData()
returns a map that stores pointers and there is no check for gettingnil
by existed keys in methodslockfreeOpen
andopen
. This potentially may causes panics.Please add checks for getting
nil
where they need to be.