Hi again IoTivity devs, I opened a JIRA ticket https://jira.iotivity.org/browse/IOT-2101 and attached a log that shows that CAdecryptSsl() has the mutex, and then GetCASecureEndpointData() is called and tries to get the mutex before CAdecryptSsl() releases it. I'm not sure which changeset introduces this problem and it's difficult to backtrack because the discovery step (which is required in order to launch the onboarding step, where this deadlock occurs) is broken in many prior commits, all the way back to when this deadlock doesn't occur.
Thanks in advance to anyone who has time to take a look at this. I've got to get back to wrapping up OCF 1.0 changes for 1.3-rel. I'll keep working around this issue as much as I can, but it's blocking at least one critical changeset for 1.3-rel. Thanks, Nathan From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Heldt-Sheller, Nathan Sent: Friday, April 21, 2017 11:26 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] apparent deadlock in GetCASecureEndpointInfo()... known issue in 1.3-rel? Hi folks, I'm blocked in verifying some of my changes because the "provisioningclient" apps seems to no longer work on 1.3-rel (72e1ab0da3a9ce08e5423b64cb793b3b57493587). Discovery of the unowned device works, but when I try to do JustWorks owner transfer I get: "09:22.701 DEBUG: OIC_OTM: In DTLSHandshakeCB(endpoint = 0x1934678, info = 0x7f3888087360) 09:22.701 INFO: OIC_OTM: Received status from remote device(fe80::fdfe:3ae0:2a84:fd81%ens33:47305) : 0 09:22.701 DEBUG: OIC_OTM_CTX: IN GetOTMContext 09:22.701 DEBUG: OIC_OTM_CTX: Found the OTMContext for [fe80::fdfe:3ae0:2a84:fd81%ens33:47305] 09:22.701 DEBUG: OIC_OTM: IN OwnershipTransferSessionEstablished 09:22.701 DEBUG: OIC_OTM: IN GetAndVerifyDoxmResource 09:22.701 DEBUG: OIC_OTM: Query=coaps://[fe80::fdfe:3ae0:2a84:fd81%25ens33]:47305/oic/sec/doxm 09:22.701 INFO: OIC_RI_STACK: Entering OCDoResource 09:22.701 DEBUG: OIC_RI_STACK: OCDoRequest: adapter = 1, flags = 48 09:22.701 DEBUG: OIC_RI_STACK: remoteId of devAddr : 09:22.701 DEBUG: OIC_CA_CONN_MGR: CAGenerateToken 09:22.705 DEBUG: OIC_CA_PRTCL_MSG: token len:8, token: 09:22.705 DEBUG: OIC_CA_PRTCL_MSG: 8F 83 76 E2 0D 08 C2 A7 09:22.705 INFO: OIC_RI_CLIENTCB: Adding client callback with token 09:22.705 INFO: OIC_RI_CLIENTCB: 8F 83 76 E2 0D 08 C2 A7 09:22.705 INFO: OIC_RI_CLIENTCB: Added Callback for uri : /oic/sec/doxm 09:22.705 DEBUG: OIC_CA_CONN_MGR: IN CAGetSecurePeerInfo 09:22.705 DEBUG: OIC_CA_CONN_MGR: OUT CAGetSecurePeerInfo 09:22.705 DEBUG: OIC_CA_NET_SSL: In GetCASecureEndpointData" ...and there it hangs. This code appears to use the g_sslContextMutex and by appearances is hanging on that oc_mutex_lock() call. Is this a known issue and is anyone working on it? Thanks, Nathan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170421/c2c0aa79/attachment.html>
