Nil pointer dereference when using the Traverse() function

[Xeckt]

When using the Traverse() function with only it's implicit behaviour (currently in dev branch only), eventually the traversal will raise a runtime error and panic.

Reproducible with the following code:

func main() {
    r := reggie.New()
    r.RootKey = registry.CURRENT_USER
    r.Path = `SOFTWARE`
    r.Permission = registry.ALL_ACCESS
    err := r.GetKeysValues()
    if err != nil {
        fmt.Println(err)
        return
    }
    err = reggie.Traverse(r, func(reg *reggie.Reg) {
        if reg != nil {
            fmt.Printf("\nPath: %s", reg.Path)
        }
    })
    if err != nil {
        fmt.Println(err)
    }
}

What seems to happen is the SubKey struct becomes <nil>. This was identified through some basic print debugging:

func (s *SubKey) OpenKey(populateKeyValues bool) (*Reg, error) {
    fmt.Println("OPENING KEY", s)
    k := Reg{
        RootKey:    s.Key.RootKey,
        Path:       s.Key.Path,
        Permission: s.Key.Permission,
        SubKeys:    make(map[string]*SubKey),
    }
...

The error that generates

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x56035e]

Output given just before error (giving last two keys opened)

Path: SOFTWARE\ej-technologies\exe4j
DEBUG:  &{0xc0001538c0 map[]} 2147483649 &{2147483649 SOFTWARE\ej-technologies\exe4j\jvms 983103 848 map[]} map[] map[] SOFTWARE\ej-technologies\exe4j\jvms 0
OPENING KEY &{0xc0001538c0 map[]}
{2147483649 SOFTWARE\ej-technologies\exe4j\jvms 983103 0 map[]}
{2147483649 SOFTWARE\ej-technologies\exe4j\jvms 983103 0 map[c:/program files/runemate/jre/bin/java.exe:0xc000168bc0]}

Path: SOFTWARE\ej-technologies\exe4j\jvms
DEBUG:  &{0xc000153c20 map[LastWriteTime:[208 96 190 223 149 172 216 1] Version:11.0.14]} 2147483649 &{2147483649 SOFTWARE\ej-technologies\exe4j\jvms\c:/program files/runemate/jre/bin/java.exe 983103 860 map[]} map[LastWriteTime:[
208 96 190 223 149 172 216 1] Version:11.0.14] map[] SOFTWARE\ej-technologies\exe4j\jvms\c:/program files/runemate/jre/bin/java.exe 0
OPENING KEY <nil>

You can see that the opening key has a pointer during traversal of multiple registry keys, but eventually turns <nil> when working its way down.

The reason why is unknown but this is something that urgently needs a stable fix.

Sigh, what a problematic error.

[Xeckt]

So it seems the problem is rooted in the filepath.Base() function. I ran into a problematic registry key tree:

ej-technologies -> [key]
  -- exe4j -> [ej-technologies subkey]
    --- jvms -> [exe4j subkey]
       ---- c:/program files/[redacted]/jre/bin/java.exe -> [jvms subkey - PROBLEM]

Now I don't know what kind of animal put a key name as a filepath and not as a REG_SZ value inside the key but here we are. I will have to rework how the Traverse() function handles key names. In this example the traverse function will pickup java.exe as the subkey.Path

sk, err := r.SubKeys[filepath.Base(s.Key.Path)].OpenKey(true)

[Xeckt]

This also explains why the error also appears with the below tree.

[Xeckt]

Fixed with commit e302858220f6078521a3c02880bf3e33a5ec8281