-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replace undefined variable 'type' with 'service->mType' (#25393) #4
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sieht für mich soweit richtig aus.... noch nicht getestet @ItRainsSmiles kannst du das bitte machen?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In Verbindung mit dem mdDns-BR64 Commit gibt es Probleme. Ich gehe davon aus, dass die Probleme nicht aus dieser Änderung hier hervorgehen.
Dennoch kann ich erstmal kein Approve geben.
Beispielcrash:
I (7077) mDNS: Adding 3 ip/hostname delegate succeeded
Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.
Core 0 register dump:
PC : 0x40173c78 PS : 0x00060830 A0 : 0x801742a9 A1 : 0x3fff3a90
0x40173c78: _mdns_dup_interface at /Users/davidernst/ELTAKO/esp-idf/components/mdns/mdns.c:2505
A2 : 0x3fff3b2e A3 : 0x00000000 A4 : 0x00000000 A5 : 0x00000000
A6 : 0x00000000 A7 : 0x0000021f A8 : 0x3fff5364 A9 : 0x00000054
A10 : 0x3ffce310 A11 : 0x00000000 A12 : 0x0000000d A13 : 0x3ffce320
A14 : 0x0000002a A15 : 0x2a77e3fe SAR : 0x00000018 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000233 LBEG : 0x4000c349 LEND : 0x4000c36b LCOUNT : 0xffffffff
Backtrace: 0x40173c75:0x3fff3a90 0x401742a6:0x3fff3ac0 0x401743de:0x3fff3b20 0x4017636f:0x3fff3b60 0x400955ed:0x3fff3bc0
0x40173c75: _mdns_dup_interface at /Users/davidernst/ELTAKO/esp-idf/components/mdns/mdns.c:2504
0x401742a6: _mdns_dispatch_tx_packet at /Users/davidernst/ELTAKO/esp-idf/components/mdns/mdns.c:1164
0x401743de: _mdns_send_bye at /Users/davidernst/ELTAKO/esp-idf/components/mdns/mdns.c:1947
(inlined by) _mdns_send_bye at /Users/davidernst/ELTAKO/esp-idf/components/mdns/mdns.c:1938
0x4017636f: _mdns_tx_handle_packet at /Users/davidernst/ELTAKO/esp-idf/components/mdns/mdns.c:4246
(inlined by) _mdns_execute_action at /Users/davidernst/ELTAKO/esp-idf/components/mdns/mdns.c:4516
(inlined by) _mdns_service_task at /Users/davidernst/ELTAKO/esp-idf/components/mdns/mdns.c:4649
0x400955ed: vPortTaskWrapper at /Users/davidernst/ELTAKO/esp-idf/components/freertos/port/xtensa/port.c:142
* Fix ThreadSanitizer failure in controller factory. The failure looks like this: WARNING: ThreadSanitizer: race on NSMutableArray (pid=11619) Read-only access of NSMutableArray at 0x7b0c0005f5b0 by thread T3: #0 -[__NSArrayM countByEnumeratingWithState:objects:count:] <null>:2 (CoreFoundation:x86_64+0x4a338) #1 -[MTRDeviceControllerFactory(InternalMethods) operationalInstanceAdded:] MTRDeviceControllerFactory.mm:855 (Matter:x86_64+0x1fd2a) #2 MTROperationalBrowser::OnBrowse(_DNSServiceRef_t*, unsigned int, unsigned int, int, char const*, char const*, char const*, void*) MTROperationalBrowser.mm:100 (Matter:x86_64+0x20ee63c) #3 handle_browse_response <null>:2 (libsystem_dnssd.dylib:x86_64+0x3733) #4 _dispatch_client_callout <null>:2 (libdispatch.dylib:x86_64+0x3316) Previous modifying access of NSMutableArray at 0x7b0c0005f5b0 by main thread: #0 -[__NSArrayM addObject:] <null>:2 (CoreFoundation:x86_64+0x2457a) #1 -[MTRDeviceControllerFactory createController] MTRDeviceControllerFactory.mm:719 (Matter:x86_64+0x1cee3) #2 -[MTRDeviceControllerFactory createControllerOnExistingFabric:error:] MTRDeviceControllerFactory.mm:534 (Matter:x86_64+0x19792) The basic problem is that we are in the middle of adding an object to _controllers on the API consumer thread when on the Matter thread we get our browse notification. The changes here don't aim to lock around all access to _controllers, but just to make sure that our mutations of it can't race with the access on the Matter thread. More coarse locking would need to be done very carefully, given the amount of dispath_sync to the Matter thread we have going on. * Address review comments.
…ist". (project-chip#29666) The typical failure there looks like this: ==29620==ERROR: LeakSanitizer: detected memory leaks Direct leak of 88 byte(s) in 1 object(s) allocated from: #0 0x106396e12 in calloc+0xa2 (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x51e12) #1 0x7ff800dc9789 in map_images_nolock+0x24b (libobjc.A.dylib:x86_64h+0x1789) #2 0x7ff800dc94db in map_images+0x42 (libobjc.A.dylib:x86_64h+0x14db) #3 0x113d721fa in invocation function for block in dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*))+0x112 (dyld:x86_64+0xf1fa) #4 0x113d6d6c8 in dyld4::RuntimeState::withLoadersReadLock(void () block_pointer)+0x28 (dyld:x86_64+0xa6c8) #5 0x113d720e1 in dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*))+0x51 (dyld:x86_64+0xf0e1) #6 0x113d85d44 in dyld4::APIs::_dyld_objc_notify_register(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*))+0x4e (dyld:x86_64+0x22d44) #7 0x7ff800dc9343 in _objc_init+0x4fe (libobjc.A.dylib:x86_64h+0x1343) #8 0x7ff800d83992 in _os_object_init+0xc (libdispatch.dylib:x86_64+0x2992) #9 0x7ff800d911b7 in libdispatch_init+0x136 (libdispatch.dylib:x86_64+0x101b7) #10 0x7ff80bd34894 in libSystem_initializer+0xed (libSystem.B.dylib:x86_64+0x1894) project-chip#11 0x113d77e4e in invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const+0xb5 (dyld:x86_64+0x14e4e) project-chip#12 0x113d9eaac in invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const+0xf1 (dyld:x86_64+0x3baac) project-chip#13 0x113d95e25 in invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0x22c (dyld:x86_64+0x32e25) project-chip#14 0x113d64db2 in dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const+0x80 (dyld:x86_64+0x1db2) project-chip#15 0x113d95bb6 in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const+0xb2 (dyld:x86_64+0x32bb6) project-chip#16 0x113d9e603 in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const+0x1d1 (dyld:x86_64+0x3b603) project-chip#17 0x113d77d81 in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const+0x8f (dyld:x86_64+0x14d81) project-chip#18 0x113d7e659 in dyld4::PrebuiltLoader::runInitializers(dyld4::RuntimeState&) const+0x1d (dyld:x86_64+0x1b659) project-chip#19 0x113d8b76d in dyld4::APIs::runAllInitializersForMain()+0x25 (dyld:x86_64+0x2876d) project-chip#20 0x113d6938c in dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*)+0xd72 (dyld:x86_64+0x638c) project-chip#21 0x113d684e3 in start+0x183 (dyld:x86_64+0x54e3)
Fix build error in case esp-idf's mDNS implementation is used