the tv-app occurred native crash，when wrote onoff attribute

[nicelyjust]

Problem

the tv-app was commissioned by chip-tool，when i tested TC-OO-2.2, the tv-app occurred native crash：
app-onoff-error.txt
i found that if you execute app::Clusters::OnOff::Attributes::OnOff::Set(static_cast<chip::EndpointId>(endpoint), value);，the tv-app must be crashed

[nicelyjust]

full log

[bzbarsky-apple]

Relevant part of the log:

08-08 16:51:28.376 E/DL      (19400): Chip stack locking error at '../../examples/tv-app/android/third_party/connectedhomeip/src/app/util/attribute-storage.cpp:549'. Code is unsafe/racy
...
08-08 16:51:28.699 F/DEBUG   (19480):       #03 pc 00000000001be0cc  /data/app/~~RL33Ljpo3ELRX4IAaR5Ynw==/com.matter.tv.server-wX8VRolotStmt3f9FXbxyA==/lib/arm64/libTvApp.so (chip::Platform::Internal::AssertChipStackLockedByCurrentThread(char const*, int)+60)
08-08 16:51:28.699 F/DEBUG   (19480):       #04 pc 00000000000733f4  /data/app/~~RL33Ljpo3ELRX4IAaR5Ynw==/com.matter.tv.server-wX8VRolotStmt3f9FXbxyA==/lib/arm64/libTvApp.so (emAfReadOrWriteAttribute(EmberAfAttributeSearchRecord*, EmberAfAttributeMetadata const**, unsigned char*, unsigned short, bool)+80)
08-08 16:51:28.699 F/DEBUG   (19480):       #05 pc 000000000007577c  /data/app/~~RL33Ljpo3ELRX4IAaR5Ynw==/com.matter.tv.server-wX8VRolotStmt3f9FXbxyA==/lib/arm64/libTvApp.so (emAfWriteAttribute(unsigned short, unsigned int, unsigned int, unsigned char*, unsigned char, bool, bool)+140)
08-08 16:51:28.699 F/DEBUG   (19480):       #06 pc 0000000000075b74  /data/app/~~RL33Ljpo3ELRX4IAaR5Ynw==/com.matter.tv.server-wX8VRolotStmt3f9FXbxyA==/lib/arm64/libTvApp.so (emberAfWriteAttribute(unsigned short, unsigned int, unsigned int, unsigned char*, unsigned char)+72)
08-08 16:51:28.699 F/DEBUG   (19480):       #07 pc 00000000000820b4  /data/app/~~RL33Ljpo3ELRX4IAaR5Ynw==/com.matter.tv.server-wX8VRolotStmt3f9FXbxyA==/lib/arm64/libTvApp.so (chip::app::Clusters::OnOff::Attributes::OnOff::Set(unsigned short, bool)+124)
08-08 16:51:28.699 F/DEBUG   (19480):       #08 pc 000000000006bfc4  /data/app/~~RL33Ljpo3ELRX4IAaR5Ynw==/com.matter.tv.server-wX8VRolotStmt3f9FXbxyA==/lib/arm64/libTvApp.so (OnOffManager::SetOnOff(int, bool)+48)
08-08 16:51:28.699 F/DEBUG   (19480):       #09 pc 000000000006c664  /data/app/~~RL33Ljpo3ELRX4IAaR5Ynw==/com.matter.tv.server-wX8VRolotStmt3f9FXbxyA==/lib/arm64/libTvApp.so (Java_com_matter_tv_server_tvapp_TvApp_setOnOff+56)
08-08 16:51:28.699 F/DEBUG   (19480):       #10 pc 000000000013ced4  /apex/com.android.art/lib64/libart.so (art_quick_generic_jni_trampoline+148) (BuildId: 2cc47e90cab939f919f347ffb2e8950a)
08-08 16:51:28.699 F/DEBUG   (19480):       #11 pc 0000000000133564  /apex/com.android.art/lib64/libart.so (art_quick_invoke_stub+548) (BuildId: 2cc47e90cab939f919f347ffb2e8950a)
08-08 16:51:28.699 F/DEBUG   (19480):       #12 pc 00000000001a8a78  /apex/com.android.art/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200) (BuildId: 2cc47e90cab939f919f347ffb2e8950a)

At first glance, OnOffManager::SetOnOff should be either taking locks or queuing things to the Matter thread.

@xylophone21 @chrisdecenzo

[nicelyjust]

it seems be good through add stacklock lock

jboolean OnOffManager::SetOnOff(jint endpoint, bool value)
{
    chip::DeviceLayer::StackLock stack;
    EmberAfStatus status = app::Clusters::OnOff::Attributes::OnOff::Set(static_cast<chip::EndpointId>(endpoint), value);
    return status == EMBER_ZCL_STATUS_SUCCESS;
}

I'm not sure this is the correct way to solve the problem @bzbarsky-apple @chrisdecenzo @lazarkov

[bzbarsky-apple]

That is certainly one valid way to solve the problem, yes.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[yunhanw-google]

@nicelyjust is this crash happening in latest code?

[chrisdecenzo]

I will fix

[chrisdecenzo]

should be fixed now

[nicelyjust]

yes，it's good now @yunhanw-google @chrisdecenzo