Skip to content
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

[BUG] uninitialized PairingCommand::mDiscriminator leads "chip-tool pairing onnetwork" to die #34096

Closed
mhwang408 opened this issue Jun 27, 2024 · 2 comments · Fixed by #34115
Labels
bug Something isn't working linux needs triage

Comments

@mhwang408
Copy link

mhwang408 commented Jun 27, 2024

Reproduction steps

  1. run all-clusters-app
  2. run ./chip-tool pairing onnetwork 1 20202021
  3. it dies as follows:
    CHIP:IN: TransportMgr initialized
    CHIP:TOO: Discovered Device: fe80::8eea:1bff:fe30:da3d:5540
    CHIP:SPT: VerifyOrDie failure at src/lib/support/SetupDiscriminator.h:52: discriminator == (discriminator & kLongMask)

The backtrace may help:
Thread 2 "chip-tool" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff41ff700 (LWP 539989)]
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007ffff78d7859 in __GI_abort () at abort.c:79
#2 0x0000555556d178f1 in chip::SetupDiscriminator::SetLongValue(unsigned short) ()
#3 0x0000555556d121c5 in chip::RendezvousParameters::SetDiscriminator(unsigned short) ()
#4 0x0000555556d0f16a in PairingCommand::Pair(unsigned long, chip::Transport::PeerAddress) ()
#5 0x0000555556d15184 in PairingCommand::OnDiscoveredDevice(chip::Dnssd::CommissionNodeData const&) ()
#6 0x00005555570acdd9 in chip::Controller::AbstractDnssdDiscoveryController::OnNodeDiscovered(chip::Variant<chip::Dnssd::CommissionNodeData, chip::Dnssd::OperationalNodeBrowseData> const&)
()
#7 0x000055555711ad5f in chip::Controller::DeviceCommissioner::OnNodeDiscovered(chip::Variant<chip::Dnssd::CommissionNodeData, chip::Dnssd::OperationalNodeBrowseData> const&) ()
#8 0x0000555556d7c7d2 in chip::Dnssd::DiscoveryContext::OnNodeDiscovered(chip::Variant<chip::Dnssd::CommissionNodeData, chip::Dnssd::OperationalNodeBrowseData> const&) ()
#9 0x0000555556d79a4f in chip::Dnssd::(anonymous namespace)::MinMdnsResolver::AdvancePendingResolverStates() ()
#10 0x0000555556d6f2b6 in chip::Dnssd::(anonymous namespace)::MinMdnsResolver::OnMdnsPacketData(mdns::Minimal::BytesRange const&, chip::Inet::IPPacketInfo const*) ()
#11 0x0000555556d80516 in chip::Dnssd::GlobalMinimalMdnsServer::OnResponse(mdns::Minimal::BytesRange const&, chip::Inet::IPPacketInfo const*) ()
#12 0x0000555556da701f in mdns::Minimal::ServerBase::OnUdpPacketReceived(chip::Inet::UDPEndPoint*, chip::System::PacketBufferHandle&&, chip::Inet::IPPacketInfo const*) ()
#13 0x0000555556eaae43 in chip::Inet::UDPEndPointImplSockets::HandlePendingIO(chip::BitFlags<chip::System::SocketEventFlags, unsigned char>) ()
#14 0x0000555556ea87d9 in chip::Inet::UDPEndPointImplSockets::HandlePendingIO(chip::BitFlags<chip::System::SocketEventFlags, unsigned char>, long) ()
#15 0x0000555556db2ee6 in chip::System::LayerImplSelect::HandleEvents() ()
#16 0x0000555556ecb7b2 in chip::DeviceLayer::Internal::GenericPlatformManagerImpl_POSIXchip::DeviceLayer::PlatformManagerImpl::_RunEventLoop() ()
#17 0x0000555556ecc1e9 in chip::DeviceLayer::PlatformManager::RunEventLoop() ()
#18 0x0000555556ecbd11 in chip::DeviceLayer::Internal::GenericPlatformManagerImpl_POSIXchip::DeviceLayer::PlatformManagerImpl::EventLoopTaskMain(void*) ()
#19 0x0000555555a81e29 in asan_thread_start(void*) ()
#20 0x00007ffff7f90609 in start_thread (arg=) at pthread_create.c:477
#21 0x00007ffff79d4353 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Bug prevalence

Whenever I do this

GitHub hash of the SDK that was being used

3d78493

and all the following commits.

Platform

core

Platform Version(s)

No response

Anything else?

Default initialize mDiscriminator can solve this error.

@mhwang408 mhwang408 added bug Something isn't working needs triage labels Jun 27, 2024
@github-actions github-actions bot added the linux label Jun 27, 2024
@bzbarsky-apple
Copy link
Contributor

I am guessing this is "fallout" from #33933. Before that we were not using SetupDiscriminator so did not catch the garbage value being passed in.

Initializing the value does not make sense; there is no value. Fix coming up.

bzbarsky-apple added a commit to bzbarsky-apple/connectedhomeip that referenced this issue Jun 27, 2024
Not all commands initialize the discriminator value, and the ones that don't should not use it.

Fixes project-chip#34096
bzbarsky-apple added a commit to bzbarsky-apple/connectedhomeip that referenced this issue Jun 27, 2024
Not all commands initialize the discriminator value, and the ones that don't should not use it.

Fixes project-chip#34096
@bzbarsky-apple
Copy link
Contributor

@mhwang408 Thank you for reporting this!

mergify bot pushed a commit that referenced this issue Jun 27, 2024
Not all commands initialize the discriminator value, and the ones that don't should not use it.

Fixes #34096
@mergify mergify bot closed this as completed in #34115 Jun 27, 2024
austina-csa pushed a commit to austina-csa/connectedhomeip that referenced this issue Jul 10, 2024
…ip#34115)

Not all commands initialize the discriminator value, and the ones that don't should not use it.

Fixes project-chip#34096
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working linux needs triage
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants