jsmn_parse Function return value error occurred

[pai-da-xin]

Hi, experts, An error occurred when I sent an offer to the master using Amazon echo show, The master can successfully receive the offer of echo show. But there was an error in the jsmn_parse Function , this causes an error in the handleOffer function.

It is knowing from my printing tokenCount that the value of tokenCount is equal to - 2, and the value of tokenCount is equal to 7. I don't know why?

The log printed when an error occurs is as follows:

2020-11-11 10:21:03 DEBUG lwsWssCallbackRoutine(): Client receive {"messagePayload":"v=0\r\no=- 3814078859 3814078859 IN IP4 0.0.0.0\r\ns=a 2 z\r\nc=IN IP4 0.0.0.0\r\nt=0 0\r\na=group:BUNDLE audio0 video0\r\nm=audio 1 UDP/TLS/RTP/SAVPF 96 0\r\na=candidate:1 1 UDP 2013266431 52.91.44.106 58652 typ host\r\na=candidate:2 1 TCP 1015021823 52.91.44.106 9 typ host tcptype active\r\na=candidate:3 1 TCP 1010827519 52.91.44.106 65015 typ host tcptype passive\r\na=candidate:1 2 UDP 2013266430 52.91.44.106 63672 typ host\r\na=candidate:2 2 TCP 1015021822 52.91.44.106 9 typ host tcptype active\r\na=candidate:3 2 TCP 1010827518 52.91.44.106 57093 typ host tcptype passive\r\na=setup:actpass\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=rtpmap:96 opus/48000/2\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=rtcp-mux\r\na=sendrecv\r\na=mid:audio0\r\na=ssrc:4280674715 cname:user3802745753@host-c79f8684\r\na=ice-ufrag:9qsh\r\na=ice-pwd:AT28xPvaHqEAwdV50BCFFD\r\na=fingerprint:sha-256 AA:BE:23:66:62:5C:78:6B:42:C1:1D:BF:89:81:5A:C6:51:61:21:C3:A2:7C:08:76:3F:AE:4E:58:20:8E:54:30\r\nm=video 1 UDP/TLS/RTP/SAVPF 99\r\na=candidate:1 1 UDP 2013266431 52.91.44.106 58652 typ host\r\na=candidate:2 1 TCP 1015021823 52.91.44.106 9 typ host tcptype active\r\na=candidate:3 1 TCP 1010827519 52.91.44.106 65015 typ host tcptype passive\r\na=candidate:1 2 UDP 2013266430 52.91.44.106 63672 typ host\r\na=candidate:3 2 TCP 1010827518 52.91.44.106 57093 typ host tcptype passive\r\na=candidate:2 2 TCP 1015021822 52.91.44.106 9 typ host tcptype active\r\nb=AS:2500\r\na=setup:actpass\r\na=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=rtpmap:99 H264/90000\r\na=rtcp:9 IN IP4 0.0.0.0\r\na=rtcp-mux\r\na=sendrecv\r\na=mid:video0\r\na=rtcp-fb:99 nack\r\na=rtcp-fb:99 nack pli\r\na=rtcp-fb:99 ccm fir\r\na=ssrc:2214618821 cname:user3802745753@host-c79f8684\r\na=ice-ufrag:9qsh\r\na=ice-pwd:AT28xPvaHqEAwdV50BCFFD\r\na=fingerprint:sha-256 AA:BE:23:66:62:5C:78:6B:42:C1:1D:BF:89:81:5A:C6:51:61:21:C3:A2:7C:08:76:3F:AE:4E:58:20:8E:54:30\r\n","messageType":"SDP_OFFER","senderClientId":"fb8a4d6e-a110-44fd-811c-df1527888960"} 2020-11-11 10:21:03 DEBUG lwsWssCallbackRoutine(): Client is writable 2020-11-11 10:21:03 DEBUG iceAgentValidateKvsRtcConfig(): iceLocalCandidateGatheringTimeout: 10000 ms iceConnectionCheckTimeout: 0 ms iceCandidateNominationTimeout: 10000 ms iceConnectionCheckPollingInterval: 0 ms tokenCount = -2 , sessionDescriptionJSONLen = 1480 2020-11-11 10:21:03 ERROR handleOffer(): operation returned status code: 0x1500000c 2020-11-11 10:21:03 ERROR signalingMessageReceived(): operation returned status code: 0x1500000c 2020-11-11 10:21:03 ERROR receiveLwsMessageWrapper(): operation returned status code: 0x1500000c 2020-11-11 10:21:05 DEBUG lwsWssCallbackRoutine(): Client is writable

[hassanctech]

We just released a new version 1.4.0, are you using that? We fixed a lot of minor issues, if you could please try on that latest release and let us know if you're seeing the same thing that would help.

[pai-da-xin]

I tested it with the latest version, there is still this problem.

The return value of function jsmn_parse is equal to - 2, Indicates that the character in the JSON string is invalid, Why is that.

[MushMal]

-2 returned from the jsmn parser API indicates JSMN_ERROR_INVAL which indicates that your JSON contains characters or bad JSON escaped string or unbalanced quotes.

Can't quite understand what's causing this in your offer/answer as the printed out JSON is in a valid format.

Is there any modification you've done to the codebase? Can you cleanup everything and rebuild? Is it possible you are intermixing widechar/multi-byte? JSON only handles ASCII.

Can you please capture the string right before the parser?

Could you give a little more info on your platform and OS?

How can we help you more in debugging this issue? The jsmn code is publicly available so you can debug into it.

[pai-da-xin]

My modification has nothing to do with offer / answer, the main modification is the kvswebrtcclientmaster.c file.

I printed sessiondescriptionjson using the " printf("sessionDescriptionJSON = %s \n", sessionDescriptionJSON); " command, the result is that "sessionDescriptionJSON = ¼"

I use cross compilation, my platform is "Linux wja 3.10.14isvp_turkey_1.0 #3 PREEMPT Thu Feb 21 14:40:58 CST 2019 mips GNU/Linux", system architecture is MIPS R3000.

[MushMal]

So as you see you have a bad JSON. Try to debug and find the root cause as now you know you have a bad data.

Start off with absolutely no modifications to the master sample and only then try to apply your changes one-by-one.

It could also be, as I mentioned, that your compiler interprets characters as two-byte or multi-byte which will break.

Please update the issue once you have more data or you are able to reproduce this with the stock master sample.

[pai-da-xin]

After my debugging, I found that, In the function receiveLwsMessage, the value of pMessage is different from that of pSignalingMessageWrapper->receivedSignalingMessage.signalingMessage.payload.

The value of pMessage is the received offer. But the value of pSignalingMessageWrapper->receivedSignalingMessage.signalingMessage.payload, which I printed out, is "¼".

[MushMal]

Cool, dig deeper now and try to understand how your code that listens to the received message stores and submits it to the offer handler. Are you using freed a freed pointer or using the pointer to the structure returned in the callback after the callback has exited? Are you familiar with native code and unmanaged memory?

[pai-da-xin]

I used the pSignalingMessageWrapper parameter here, printing "pSignalingMessageWrapper-> receivedSignalingMessage.signalingMessage.payload". This should be after the callback exits.

The native code is familiar with the section, But unmanaged memory doesn't understand.

[docee]

SDP needs base64 encode.

[MushMal]

@pai-da-xin this really is outside of the scope of the support we can provide. You need to ensure in your code you follow the sample or fully understand the codebase. Can you please get the sample working and only then start modifying to your application.

I am resolving this issue as it's not specific to KVS. Please cut a new issue with detailed description of the issue that pinpoints to KVS assets. If you need help or have a targeted question please note that directly in the issue so people can help with your code or technology and won't spend too much cycles looking and trying to deduce your scenario.

If you need more in-depth help or solution architecture then please do not hesitate to contact your AWS technical account management team.