[crash] Matter: __59-[MTRBaseClusterPowerSource initWithDevice:endpoint:queue:]_block_invoke #21430
Comments
bzbarsky-apple
added a commit
to bzbarsky-apple/connectedhomeip
that referenced
this issue
Aug 1, 2022
…ework. Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix project-chip#21430
bzbarsky-apple
added a commit
to bzbarsky-apple/connectedhomeip
that referenced
this issue
Aug 1, 2022
…ework. Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix project-chip#21430
bzbarsky-apple
added a commit
to bzbarsky-apple/connectedhomeip
that referenced
this issue
Aug 2, 2022
…ework. Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix project-chip#21430
bzbarsky-apple
added a commit
to bzbarsky-apple/connectedhomeip
that referenced
this issue
Aug 2, 2022
…ework. Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix project-chip#21430
bzbarsky-apple
added a commit
to bzbarsky-apple/connectedhomeip
that referenced
this issue
Aug 2, 2022
…ework. Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix project-chip#21430
woody-apple
pushed a commit
that referenced
this issue
Aug 2, 2022
…ework. (#21504) Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix #21430
github-actions bot
pushed a commit
that referenced
this issue
Aug 2, 2022
…ework. (#21504) Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix #21430
woody-apple
added a commit
that referenced
this issue
Aug 2, 2022
…ework. (#21504) (#21528) Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix #21430 Co-authored-by: Boris Zbarsky <bzbarsky@apple.com>
isiu-apple
pushed a commit
to isiu-apple/connectedhomeip
that referenced
this issue
Sep 16, 2022
…ework. (project-chip#21504) Darwin framework objects were holding on to OperationalDeviceProxy and CHIPCluster instances, but OperationalDeviceProxy can be destroyed randomly by anyone who cares to do it, and CHIPCluster is really designed as a stack-only object. This PR makes the following changes: * MTRBaseDevice now either stores a DeviceProxy (for PASE only) or a node id (for CASE). * MTRBaseCluster instances now just store a DeviceProxy. * MTRCallbackBridge will handle getting an exchange manager and session before invoking the action block, unless the action block is runnable without any remote interaction (the "read from cache" case). * Most of the MTRDevice and MTRClusters APIs that used to sync-run things on the Matter queue now do it async when doing CASE. They were changed to copy their incoming arguments to avoid the caller mutating them after the call. I believe this should fix project-chip#21430
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem
Crash reported during stability run with SHA
aa9457e6b94b735076dff6297176183bf9780177Apple reference: radar:97794001
The text was updated successfully, but these errors were encountered: