Hi, An update... I still don't know the "root cause", and cannot explain the "random" behavior of the library.
However, made some progress with limiting the scope... There were some changes in the IoTivity 2.0 source code re: building CBOR encoding, comparing to the 1.3 code base. You can see them here: https://github.com/iotivity/iotivity/commits/master/resource/csdk/stack/src/ocpayloadconvert.c Once I rolled back the 2 latest changes, the problematic "random" behavior stopped to reproduce. So I still don't understand the "root cause", but I am quite confident the issue is with the changes I mentioned. If I got it right, the changes are related to "batch / collection" we don't use in our product, so I have kind of patch / workaround for now. Unfortunately, I have no time to debug the code modifications in depth, for now. Best regards. Max. On Fri, Jul 5, 2019 at 9:37 AM <chiayu...@ite.com.tw> wrote: > Hi Max, > > > > I met a similar issue of the data size difference after doing “Post > request”. > > > > But the problem of mine is the size of received pdu of “Get response” will > be larger than regular after a “Post request” been performed. > > > > Client: Android(2.0.1) > > Server: OCSample/OCServer(2.0.1) > > > > Step1. Discovery [OK] > > Step2. Get [OK]…Get [OK]…Get [OK]… > > Step3. Post [OK] > > Step4. Get [NG], Android client crashed. > > > > The received pdu data of both cases are list below. > > The main difference appeared just after token bytes. > > received pdu data [OK]: > > 68 45 EF 0E 57 66 4D B2 3C 91 8A EC 82 01 00 31 > > 61 05 6C 69 67 68 74 12 27 10 E2 06 EC 08 00 E1 > > F6 E2 C0 FF BF 62 72 74 81 68 2F 61 2F 6C 69 67 > > 68 74 62 69 66 82 6F 6F 69 63 2E 69 66 2E 62 61 > > 73 65 6C 69 6E 65 69 6F 69 63 2E 69 66 2E 72 77 > > 65 70 6F 77 65 72 18 32 FF > > > > Msgid: EF 0E > > Token: 57 66 4D B2 3C 91 8A EC > > Difference: 82 01 > > > > received pdu data [NG]: > > 68 45 7A EC 4F CA 0D 98 6A 23 A1 C4 84 E8 3B 01 > > 00 31 61 05 6C 69 67 68 74 12 27 10 E2 06 EC 08 > > 00 E1 F6 E2 C0 FF BF 62 72 74 81 68 2F 61 2F 6C > > 69 67 68 74 62 69 66 82 6F 6F 69 63 2E 69 66 2E > > 62 61 73 65 6C 69 6E 65 69 6F 69 63 2E 69 66 2E > > 72 77 65 70 6F 77 65 72 18 32 FF > > > > Msgid: 7A EC > > Token: 4F CA 0D 98 6A 23 A1 C4 > > Difference: 84 E8 3B 01 > > > > Android log > > A/art: art/runtime/java_vm_ext.cc:410] JNI DETECTED ERROR IN APPLICATION: > input is not valid Modified UTF-8: illegal start byte 0xa8 > > > > -- > > However, if I use Android Client(2.0.1) + Android Server (2.0.1), > “Discovery”, “Get”, “Post” are all OK. > > > > Best Regards, > > ChiaYu > > > > *From:* iotivity-dev@lists.iotivity.org [mailto: > iotivity-dev@lists.iotivity.org] *On Behalf Of *Max > *Sent:* Wednesday, July 03, 2019 5:01 AM > *To:* iotivity > *Subject:* [dev] Payload issue after upgrading to IoTivity 2.0 > > > > Hi, > > > > I am in process of upgrading my Android server device from IoTivity 1.3.1 > to 2.0 (using the latest 'master'). > > > > I face a weird issue that I never saw with the previous version. > > > > "Randomly", the response to POST request to one of my resources - is > wrapped as an array. > > Normally, the response looks like: > > {"value":false,"x.com.sure.a.b":"abc"} > > > > In the buggy scenarios, appearing randomly, the data is reported by the > client as: > > [{"value":false,"x.com.sure.a.b":"abc"}] > > So the data inside the array is right, but the array [] should not be > there! > > > > Unfortunately, the only way I was able to reproduce the issue (from time > to time) is via running a specific test of the Certification Test Tool. I > failed to reproduce the bug "manually". > > > > I wonder what can be the cause of such a behavior, and how to debug it > further. > > > > I tried to look into the logs, and indeed I saw that in the "buggy" > responses, same code generates 60 bytes, instead of 59 bytes. > > > > The proper response (59 bytes) looks in the logs like: > > > > 07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0000: *44 44 3d a7 32 dc 99 > 23 b9 73 74 62 53 77 69 74 * DD=.2..#.stbSwit > 07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0010: * 63 68 12 27 10 e2 06 > ec 08 00 e1 f6 e2 c0 ff bf* ch.'............ > 07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0020: *65 76 61 6c 75 65 f4 > 6e 78 2e 63 6f 6d 2e 73 75* evalue.nx.com.su > <https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fevalue.nx.com.su&umid=1c6ea5a5-a514-46a3-a61e-a762a3e3ac61&auth=bd015149f2efa238c1c2b9bffc7d372c2eb7e6a6-344a707534c6b1f358bc3e1575ba09756c5684f3> > 07-02 15:39:33.912 10395-10566 D/MBED_TLS: 0030: *72 65 2e 61 2e 62 63 > 61 62 63 ff* re.a.bcabc. > > > > The buggy response (60 bytes) looks in the logs like:: > > > > 07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0000: *54 44 b8 1b 3b ca b1 > 13 b9 73 74 62 53 77 69 74* TD..;....stbSwit > 07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0010: *63 68 12 27 10 e2 06 > ec 08 00 e1 f6 e2 c0 ff 81* ch.'............ > 07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0020: *bf 65 76 61 6c 75 65 > f5 6e 78 2e 63 6f 6d 2e 73* .evalue.nx.com.s > 07-02 15:42:07.102 10395-10566 D/MBED_TLS: 0030: *75 72 65 2e 61 2e 62 > 63 61 62 63 ff * ure.a.bcabc. > > > > Is there any method to analyze the payload? I tried to "paste" to cbor.me > site - no success. > > > > Any hint on how to analyze the data and identify the "root cause" is > highly appreciated. > > > > > > Thanks in advance > > Max > > > > > > Max Kholmyansky > > CTO - SURE Universal Ltd. > > http://www.sureuniversal.com > <https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=http%3a%2f%2fwww.sureuniversal.com&umid=1c6ea5a5-a514-46a3-a61e-a762a3e3ac61&auth=bd015149f2efa238c1c2b9bffc7d372c2eb7e6a6-b1814f0dece526a3f0aba204ef3f411b9541712e> > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10236): https://lists.iotivity.org/g/iotivity-dev/message/10236 Mute This Topic: https://lists.iotivity.org/mt/32290813/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
