On 04/21/2017 04:09 PM, Heldt-Sheller, Nathan wrote: > 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:iotivity-dev-bounces > at lists.iotivity.org] 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:
The hope would be when this gets fixed, there can also be a regression test written that catches any future breakage in this area. Though we've already seen some hint that the jenkins unit tests don't actually force secure mode, which needs investigation...
