panic: runtime error: invalid memory address or nil pointer dereference

[Rosi1981]

go run cmd/hems/main.go 4715 <> keys/evse.crt keys/evse.key 2023-07-14 11:28:07 INFO Local SKI: 41c98b1bbe5fc7657ce311981951f12d304ab419 2023-07-14 11:28:07 DEBUG restarting mdns search 2023-07-14 11:28:07 DEBUG mdns: start search 2023-07-14 11:28:07 DEBUG starting websocket server on :4715 2023-07-14 11:28:07 DEBUG mdns: announce 2023-07-14 11:28:07 DEBUG mdns: using avahi 2023-07-14 11:28:07 DEBUG ski: <> name: Viessmann-7377953305981209 brand: model: typ: identifier: Viessmann-73779533 panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xa4613d]

goroutine 19 [running]: github.com/enbility/eebus-go/service.(mdns).resolveEntries(0xc0000b6660) /root/eebus/eebus-go-dev/service/mdns.go:338 +0x31d created by github.com/enbility/eebus-go/service.(mdns).RegisterMdnsSearch /root/eebus/eebus-go-dev/service/mdns.go:277 +0x265 exit status 2

[DerAndereAndi]

Did you really enter <> as an SKI? That information is a hash of the self signed certificate of the device. Nobody can do anything with it other than you. So hiding hit doesn't help and often leads to more issues understanding what is happening.

Which version of the code are you using? Main branch or dev branch? And which OS are you running this on?

[DerAndereAndi]

As far as I can see, this scenario should never happen. It looks like avahi is not working as it should.

Please check the code in the branch feature/mdns ( https://github.com/enbility/eebus-go/tree/feature/mdns ). That code will not work but shouldn't crash. I just need to see if my assumption is correct.

The only workaround for this would be not to use avahi in this case. But it would be good to figure out why avahi doesn't work.

[DerAndereAndi]

The branch now contains a test for the avahi browser working and will fallback if it is not properly working. With this code the panic should not occur and it should use the go implementation of zeroconf instead of the avahi daemon

[Rosi1981]

I'm using dev branch on Linux

Using /feature/mdns:

go run cmd/hems/main.go 4715 A1192A92306FAC83F54F2CC5B7FC7715C48E70A9 keys/evse.crt keys/evse.key 2023-07-14 15:48:43 INFO Local SKI: 41c98b1bbe5fc7657ce311981951f12d304ab419 2023-07-14 15:48:43 DEBUG restarting mdns search 2023-07-14 15:48:43 DEBUG mdns: start search 2023-07-14 15:48:43 DEBUG starting websocket server on :4715 panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x28 pc=0xa3e00b]

goroutine 1 [running]: github.com/holoplot/go-avahi.(Server).ServiceBrowserNew(0x0, 0x127b60?, 0xc0?, {0xb9e4c7, 0xa}, {0xb9cebb, 0x6}, 0x127b60?) /root/go/pkg/mod/github.com/holoplot/go-avahi@v1.0.1/server.go:193 +0xab github.com/enbility/eebus-go/service.(mdns).setupAvahi(0xc0000b6660) /root/eebus/eebus-go/service/mdns.go:130 +0x85 github.com/enbility/eebus-go/service.(mdns).SetupMdnsService(0xc0000b6660) /root/eebus/eebus-go/service/mdns.go:92 +0x25 github.com/enbility/eebus-go/service.(connectionsHub).start(0xc0000af360) /root/eebus/eebus-go/service/hub.go:128 +0xc5 github.com/enbility/eebus-go/service.(EEBUSService).Start.func1() /root/eebus/eebus-go/service/service.go:228 +0x25 sync.(Once).doSlow(0xa9c020?, 0xc0000a10c0?) /usr/local/go/src/sync/once.go:74 +0xc2 sync.(Once).Do(...) /usr/local/go/src/sync/once.go:65 github.com/enbility/eebus-go/service.(EEBUSService).Start(0xc0000af360?) /root/eebus/eebus-go/service/service.go:227 +0x45 main.(*hems).run(0xc0000b4038) /root/eebus/eebus-go/cmd/hems/main.go:86 +0x805 main.main() /root/eebus/eebus-go/cmd/hems/main.go:138 +0x45 exit status 2

[DerAndereAndi]

Ouch, that was a stupid bug. Could try again with the latest code in this branch?

Which Linux distribution and version is it? Can you determine which avahi version is installed? E.g. using avahi-browse --version

[Rosi1981]

I tried again with the latest code on Fedora 38 and avahi-browse 0.8, which seems to work properly:

go run cmd/hems/main.go 4715 A1192A92306FAC83F54F2CC5B7FC7715C48E70A9 keys/evse.crt keys/evse.key 2023-07-15 11:05:23 INFO Local SKI: 41c98b1bbe5fc7657ce311981951f12d304ab419 2023-07-15 11:05:23 DEBUG restarting mdns search 2023-07-15 11:05:23 DEBUG mdns: start search 2023-07-15 11:05:23 DEBUG starting websocket server on :4715 2023-07-15 11:05:23 DEBUG mdns: announce 2023-07-15 11:05:23 DEBUG mdns: using avahi 2023-07-15 11:05:23 DEBUG ski: a1192a92306fac83f54f2cc5b7fc7715c48e70a9 name: gridX\ gridBox-H083-450-000-002-375-P-X brand: model: typ: identifier: gridX-gridBox-H083-450-000-002-375-P-X register: false host: gridBox-H083-450-000-002-375-P-X.local. port: 52062 addresses: [192.168.178.115] 2023-07-15 11:05:23 DEBUG ski: b5a53a448b8e2ff412d03273c11fc5e034b07d75 name: Viessmann-7377953305981209 brand: model: typ: identifier: Viessmann-7377953305981209 register: false host: Viessmann-7736172063959223.local. port: 16369 addresses: [192.168.178.116]

[DerAndereAndi]

Thanks. Is this a different system compared to your earlier test? If not, the original code in the dev branch should also work.

I would need to know if the new code fixes the issues on the system that caused the panic

[Rosi1981]

No, it has been the same system from the beginning:

dev still segvs: go run cmd/hems/main.go 4715 A1192A92306FAC83F54F2CC5B7FC7715C48E70A9 keys/evse.crt keys/evse.key 2023-07-17 08:20:34 INFO Local SKI: 41c98b1bbe5fc7657ce311981951f12d304ab419 2023-07-17 08:20:34 DEBUG restarting mdns search 2023-07-17 08:20:34 DEBUG mdns: start search 2023-07-17 08:20:34 DEBUG starting websocket server on :4715 2023-07-17 08:20:34 DEBUG mdns: announce 2023-07-17 08:20:34 DEBUG mdns: using avahi 2023-07-17 08:20:34 DEBUG ski: b5a53a448b8e2ff412d03273c11fc5e034b07d75 name: Viessmann-7377953305981209 brand: model: typ: identifier: Viessmann-7377953305981209 register: false host: Viessmann-7736172063959223.local. port: 16369 addresses: [192.168.178.116] panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xa4613d]

goroutine 6 [running]: github.com/enbility/eebus-go/service.(mdns).resolveEntries(0xc0000786c0) /root/eebus/test/eebus-go/service/mdns.go:338 +0x31d created by github.com/enbility/eebus-go/service.(mdns).RegisterMdnsSearch /root/eebus/test/eebus-go/service/mdns.go:277 +0x265 panic: send on closed channel

goroutine 19 [running]: github.com/DerAndereAndi/zeroconf/v2.(client).mainloop(0xc00009c300, {0xd7b578, 0xc000096190}, 0xc0000c4000) /root/go/pkg/mod/github.com/!der!andere!andi/zeroconf/v2@v2.0.0-20230702124214-98a3b1bb316f/client.go:316 +0x16da github.com/DerAndereAndi/zeroconf/v2.(client).run.func1() /root/go/pkg/mod/github.com/!der!andere!andi/zeroconf/v2@v2.0.0-20230702124214-98a3b1bb316f/client.go:120 +0x68 created by github.com/DerAndereAndi/zeroconf/v2.(*client).run /root/go/pkg/mod/github.com/!der!andere!andi/zeroconf/v2@v2.0.0-20230702124214-98a3b1bb316f/client.go:118 +0xef exit status 2

feature/mdns does the job: go run cmd/hems/main.go 4715 A1192A92306FAC83F54F2CC5B7FC7715C48E70A9 keys/evse.crt keys/evse.key 2023-07-17 08:22:26 INFO Local SKI: 41c98b1bbe5fc7657ce311981951f12d304ab419 2023-07-17 08:22:26 DEBUG restarting mdns search 2023-07-17 08:22:26 DEBUG mdns: start search 2023-07-17 08:22:26 DEBUG starting websocket server on :4715 2023-07-17 08:22:26 DEBUG mdns: announce 2023-07-17 08:22:26 DEBUG mdns: using avahi 2023-07-17 08:22:26 DEBUG ski: a1192a92306fac83f54f2cc5b7fc7715c48e70a9 name: gridX\ gridBox-H083-450-000-002-375-P-X brand: model: typ: identifier: gridX-gridBox-H083-450-000-002-375-P-X register: false host: gridBox-H083-450-000-002-375-P-X.local. port: 52062 addresses: [192.168.178.115] 2023-07-17 08:22:26 DEBUG ski: b5a53a448b8e2ff412d03273c11fc5e034b07d75 name: Viessmann-7377953305981209 brand: model: typ: identifier: Viessmann-7377953305981209 register: false host: Viessmann-7736172063959223.local. port: 16369 addresses: [192.168.178.116]

[DerAndereAndi]

Thanks @Rosi1981 . This is very weird. All I did is adding a check if an avahi feature is available and if not it should fall back to the go implementation. But it doesn't fall back with this check and instead enables avahi. Maybe this is a timing issue with dbus or something completely different.

Thank you anyway for checking this out. I will merge the change then.