Hi Lukas. Recently we discovered an issue with avahi browser. During automated test we have observed some coredumps caused by p44::ServiceBrowser. To trigger avahi browse (all services), we have to create new ServiceBrowser object. Unfortunately we have some timing issues there, when during object destroying browser received some data.
example:
[2019-04-19 12:42:46.537 I] ServiceBrowser: NEW service 'Doorstation - 1CCAE37BFCEE' of type '_axis-video._tcp' in domain 'local' -> resolving now
[2019-04-19 12:42:46.582 I] vdSM -> vDC (pbuf) method call received: requestid='2173', method='genericRequest', params={ dSUID:"04D44CB1EF185365C05239402755CA1800", methodname:"scanDevices", params:{ clearconfig:false, exhaustive:false, incremental:true } }
[2019-04-19 12:42:46.583 N] >>>> ++++ 0x3c559b10 (2)
[2019-04-19 12:42:46.585 N] >>>> ---- 0x3c54c040 (1)
[2019-04-19 12:42:46.586 I] vdSM <- vDC (pbuf) result sent: requestid='2173', result=NULL
[2019-04-19 12:42:46.586 N] >>> resolve_callback 0x3c54c040
[2019-04-19 12:42:46.586 D] avahi: resolved service 'Doorstation - 1CCAE37BFCEE' of type '_axis-video._tcp' in domain 'local' at 192.168.0.138:
[2019-04-19 12:42:48.174 D] Initiating connection to 255.255.255.255:35344
[2019-04-19 12:42:48.174 D] Connectionless socket ready for address family = 2, protocol = 0
[2019-04-19 12:42:48.174 N] *** starting initialisation of vcd host 'Doorbird Controller @dssip-devel' (Instance #0)
*** Product name: 'vdc-doorbird', Product Version: '1.2.0', Device Hardware ID: ''
*** dSUID (external) = 302ED89F43F00000000031A80016245E62, MAC: 00:0F:A3:16:24:5E, IP = 192.168.0.198Service Browser is passed to callback as void pointer, obviously because this is the only way to get the object back, but because of void* there is no way to verify if ServiceBrowser* is valid. My proposal to improve ServiceBrowser is to create interface to trigger service browser on demand. It allows the to control the lifetime of ServiceBrowser in case when browse is triggered many times.