On Aug 4, 2016 2:00 PM, "Dave Thaler" <dthaler at microsoft.com> wrote: > > Jenkins should be running the tests to verify every checkin. >
Ah, good point. Still, I downloaded the 1.1.1 tarball, compiled it with TEST=1 and got errors. So either my system is hosed or Jenkins is not right in the head. If you (or anybody else) could find the time to run the 1.1.1 tarball with TEST=1 and report the results I would be most grateful. Gregg > > > From: iotivity-dev-bounces at lists.iotivity.org [mailto: iotivity-dev-bounces at lists.iotivity.org] On Behalf Of Gregg Reynolds > Sent: Thursday, August 4, 2016 11:57 AM > To: iotivity-dev <iotivity-dev at lists.iotivity.org> > Subject: Re: [dev] provisioning unittest fails > > > > I'm the only guy who runs the unit tests? > > Could somebody at least say "works for me"? > > -gregg > > > > On Aug 3, 2016 1:24 PM, "Gregg Reynolds" <dev at mobileink.com> wrote: >> >> >> >> >> >> On Mon, Aug 1, 2016 at 12:21 PM, Gregg Reynolds <dev at mobileink.com> wrote: >>> >>> Hi all, >>> >>> >>> >>> After pulling in the latest changes from master (this is Iotivity on Ubuntu 14.04, not Iochibity, although I see the same thing in both places) I'm seeing the following test failures. I'm running tests without valgrind. >> >> >> >> Same thing with the 1.1.1 tarball. Am I the only one running the tests? >> >> >> >> ~/iotivity-1.1.1$ scons . SECURED=1 TEST=1 VERBOSE=true 2>&1 | tee log.1.1.1 >> >> ... >> >> [ RUN ] InitForOTM.NullParam >> >> 20:05.120 DEBUG: PDM: (21) misuse at line 129790 of [cf538e2783] >> >> 20:05.120 INFO: PDM: Unable to enable debug log of sqlite >> >> 20:05.120 DEBUG: PDM: (14) cannot open file at line 31775 of [cf538e2783] >> >> 20:05.120 DEBUG: PDM: (14) os_unix.c:31775: (2) open(/home/gar/iotivity/iotivity-1.1.1/out/linux/x86_64/release/resource/csdk/security/provisioning/unittest/test.db) - >> >> 20:05.120 INFO: PDM: ERROR: Can't open database: unable to open database file >> >> 20:05.144 INFO: PDM: Created T_DEVICE_LIST >> >> 20:05.148 INFO: PDM: Created T_DEVICE_LINK_STATE >> >> 20:05.148 DEBUG: OTM: IN OTMSetOwnerTransferCallbackData >> >> 20:05.148 DEBUG: OTM: OUT OTMSetOwnerTransferCallbackData >> >> [ OK ] InitForOTM.NullParam (2034 ms) >> >> [----------] 1 test from InitForOTM (2034 ms total) >> >> >> >> [----------] 1 test from PerformUnownedDeviceDiscovery >> >> [ RUN ] PerformUnownedDeviceDiscovery.NullParam >> >> 20:05.148 DEBUG: PM-UTILITY: IN PMDeviceDiscovery >> >> 20:05.148 DEBUG: PM-UTILITY: Successfully converted doxm cbor to bin. >> >> 20:05.148 ERROR: PM-UTILITY: Error while getting my device ID. >> >> 20:05.168 DEBUG: PM-UTILITY: Successfully converted doxm cbor to bin. >> >> 20:05.168 ERROR: PM-UTILITY: Error while getting my device ID. >> >> 20:05.168 DEBUG: PM-UTILITY: Successfully converted doxm cbor to bin. >> >> 20:05.168 ERROR: PM-UTILITY: Error while getting my device ID. >> >> 20:05.236 DEBUG: PM-UTILITY: Successfully converted doxm cbor to bin. >> >> 20:05.236 ERROR: PM-UTILITY: Error while getting my device ID. >> >> 20:05.240 DEBUG: PM-UTILITY: Successfully converted doxm cbor to bin. >> >> 20:05.240 ERROR: PM-UTILITY: Error while getting my device ID. >> >> 20:05.240 DEBUG: PM-UTILITY: Successfully converted doxm cbor to bin. >> >> 20:05.240 ERROR: PM-UTILITY: Error while getting my device ID. >> >> 20:08.684 DEBUG: PM-UTILITY: OUT PMDeviceDiscovery >> >> resource/csdk/security/provisioning/unittest/otmunittest.cpp:399: Failure >> >> Value of: NumOfUnownDevice >> >> Actual: 0 >> >> Expected: 2 >> >> [ FAILED ] PerformUnownedDeviceDiscovery.NullParam (3540 ms) >> >> [----------] 1 test from PerformUnownedDeviceDiscovery (3540 ms total) >> >> >> >> [----------] 1 test from PerformJustWorksOxM >> >> [ RUN ] PerformJustWorksOxM.NullParam >> >> resource/csdk/security/provisioning/unittest/otmunittest.cpp:408: Failure >> >> Value of: result >> >> Actual: 26 >> >> Expected: OC_STACK_OK >> >> Which is: 0 >> >> ^C >> >> >> >> >> >> >> >> >>> >>> >>> >>> $ scons --config=force VERBOSE=TRUE SECURED=1 TEST=1 2>&1 | tee build.log >>> >>> ... >>> >>> ... /resource/csdk/security/provisioning/unittest/unittest >>> >>> ... >>> >>> >>> >>> [----------] 1 test from PerformUnownedDeviceDiscovery >>> >>> [ RUN ] PerformUnownedDeviceDiscovery.NullParam >>> >>> resource/csdk/security/provisioning/unittest/otmunittest.cpp:399: Failure >>> >>> Value of: NumOfUnownDevice >>> >>> Actual: 0 >>> >>> Expected: 2 >>> >>> [ FAILED ] PerformUnownedDeviceDiscovery.NullParam (4000 ms) >>> >>> [----------] 1 test from PerformUnownedDeviceDiscovery (4000 ms total) >>> >>> >>> >>> [----------] 1 test from PerformJustWorksOxM >>> >>> [ RUN ] PerformJustWorksOxM.NullParam >>> >>> resource/csdk/security/provisioning/unittest/otmunittest.cpp:408: Failure >>> >>> Value of: result >>> >>> Actual: 26 >>> >>> Expected: OC_STACK_OK >>> >>> Which is: 0 >>> >>> >>> >>> What's happening with the first fail is that the test suite launches a couple of sampleserver apps in the preceding step and then it runs PMDeviceDiscovery. If I run the tests with LOGGING=TRUE it's clear that the devices (or at least one of them) are responding. The problem seems to be that DeviceDiscoveryHandler (in pmutility.c) then calls GetDoxmDevOwnerId(&myId), which fails, which causes the Doxm data from the payload to be deleted. At least I think that's the problem: >>> >>> >>> >>> 11:47.552 INFO: OIC_RI_PAYLOADPARSE: Finished parse payload, result is 0 >>> >>> 11:47.552 DEBUG: PM-UTILITY: Successfully converted doxm cbor to bin. >>> >>> 11:47.552 DEBUG: SRM-DOXM: GetDoxmDevOwnerId(): gDoxm owned = 0. >>> >>> 11:47.552 ERROR: PM-UTILITY: Error while getting my device ID. >>> >>> ... >>> >>> resource/csdk/security/provisioning/unittest/otmunittest.cpp:399: Failure >>> >>> >>> >>> GetDoxmDevOwnerId references gDoxm, which is a global var in doxmresource.c. >>> >>> >>> >>> Any idea what's going on? Is something not getting initialized properly here? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Gregg >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160804/e943909d/attachment.html>
