<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; ">Hi,</div><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; "><br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; ">1. I didn't change any thing in libnice and my application run well on x86 computer.</div><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; ">2. Is this debug line is normal ?</div><div>(sofsip_cli:1573): libnice-DEBUG: Agent 0xc1610 : STUN-CC REQ to '192.168.1.43:40183', socket=15, pair=1:1 (c-id:1), tie=10819118275753794247, username='GbRO:fHIZ' (9), password='EQTzkej5Ba4EGqMjCRCMMJ' (22), priority=1845494271.<br></div><div>I saw that username here is "remote_username:local_username" ( length = 9) but password has only  remote password.</div><div><br></div><div>If this
 normal, then the problem occur in conn_check_send() function at conncheck.c</div><div><div>buffer_len = stun_usage_ice_conncheck_create (&agent->stun_agent,</div><div>        &pair->stun_message, pair->stun_buffer, sizeof(pair->stun_buffer),</div><div>        uname, uname_len, password, password_len,</div><div>        cand_use, controlling, priority,</div><div>        agent->tie_breaker,</div><div>        pair->foundation,</div><div>        agent_to_ice_compatibility (agent));</div><div><br></div><div>This function change the username, password and length value.</div><div>The backtrace show difference username, username length, password, password length.</div></div><div><div> md5 = "\207\235\f\000\026\000\000\000\377\001\000n\307\332", <incomplete sequence \351></div><div>#6  0x3ac02a7c in
 conn_check_send (agent=0xc1610, pair=0xf38b8) at conncheck.c:1635</div><div>        priority = 97240</div><div>        uname = "GbRO:fHIZ\000\000\000\004\000\000\000|P\377\256\\/\317L\000\000\000\000LO\377\256\020\370\v\000\200\067\001\000\240u\001\000\001\000\000\000\002\000\000\000\004\000\000\000\000\000\000\000\005\000\000\000Py\263L\000u`\313\000\000\000\000\314\066\001\000@\n\004\000\200\251\004\000\020\026\f\000\200\251\004\000\000\000\000\000\004\000\000\000|P\377\256\004\000\000\000\020\026\f\000\244O\377\256\000\000\000\000X\237\300:\370x\001\000\001\000\000\000\020\370\v\000\000\000\000\000h9\020\000\340\362\016\000\020\026\f\000X\363\016\000\000\000\000\000\001\000\000\000\220\344\f\000\004\060\300:\002\000\000@\270\300\003\000\020t\002\000\026\000\000\000\020\026\f\000p\232\f\000\020\026\f\000\004\000\000\000\000\000\000\000|P\377\256 \260\n\000\000\000\000\000\300\207\301:t\207\301:
 \260\n\000\000\000\000\000\260\016\237L\250"...</div><div>        uname_len = 997580</div><div>        password = 0xc9d87 "EQTzkej5Ba4EGqMjCRCMMJ"</div><div>        password_len = 997580</div><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; "><br></div><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; ">If you have N9 device, I will send you the source code problem.</div></div><div style="font-family: arial, helvetica, sans-serif; font-size: 12pt; ">Thanks</div>  <div style="font-size: 12pt; font-family: arial, helvetica, sans-serif; "> <div style="font-size: 12pt; font-family: 'times new roman', 'new york', times, serif; "> <div dir="ltr"> <font size="2" face="Arial"> <hr size="1">  <b><span style="font-weight:bold;">From:</span></b> Youness Alaoui <youness.alaoui@collabora.co.uk><br> <b><span style="font-weight: bold;">To:</span></b>
 nice@lists.freedesktop.org; congly85@yahoo.com <br> <b><span style="font-weight: bold;">Sent:</span></b> Friday, August 17, 2012 3:53 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9)<br> </font> </div> <br>
Hi,<br><br>I see you added a lot of debug to figure out the issue. But this looks<br>completely wrong.<br>Libnice itself works fine on ARM (it is shipped and used by Meego/Harmattan on<br>the N9) and it looks like there is some sort of stack corruption in the backlog<br>you sent me...<br>The &pair->stun_message could not be NULL, because stun_message is not a<br>dynamically allocated pointer, it's structure inside the CandidateCheckPair<br>structure and it's returning its pointer so it can't be NULL (unless 'pair' is<br>equal to exactly the negative value of the offset in the structure of the<br>stun_message field).<br>What I could analyze is this :<br>The crash happens in memcpy called by SHA1Transform when it tries to copy data<br>(to sha1) to an internal buffer. The reason is that the source data it tries to<br>copy is outside the allocated memory.<br>The problem is that it thinks the size of the data that needs to be hashed is<br>4294967267...
 that is equal to 0xFFFFFFE3 which is, in signed format : -29<br>The -29 comes from this :<br>  lengths[2] = len - 28;<br>Which means that the original length of the stun message was thought to be<br>"-1"... that in itself makes no sense because the length is returned from<br>stun_message_length() which itself is :<br>uint16_t stun_message_length (const StunMessage *msg)<br>{<br>  return stun_getw (msg->buffer + STUN_MESSAGE_LENGTH_POS) +<br>      STUN_MESSAGE_HEADER_LENGTH;<br>}<br><br>the STUN_MESSAGE_HEADER_LENGTH is equal to 20, and the stun_getw is just<br>returning the uint16 value in the (buffer + 2) memory... so for the<br>stun_message_length to return -1, it means that the exact value at the offset 2<br>in the buffer has to be -21 since stun_message_length returns the getw + 20...<br>This seems to be consistent with what your new debug messages seem to be<br>printing. If you also add to it that in your case, you're
 saying that "msg" is<br>NULL, it means that stun_message_length shouldn't have returned -1, it should<br>have segfaulted when trying to access msg->buffer.<br><br>There's also this stuff that seems weird :<br>        uname_len = 1004972<br>        password_len = 1004972<br> key_len=2929302848, num_elem=2, (even though previous function in the stack<br>trace shows key_len = 22, and num_elem=3)<br>The problem still remains that the message_length is thought to be -1<br>(0xFFFFFFFF) and that's what's causing all the other issues. Even the 'fakelen'<br>variable (which is a htons of the len) is set to 65535.<br><br>From all this, all I can conclude is that, you're either doing something wrong,<br>or you're using a heavily modified library which I have no idea what it does, or<br>your ram/whatever is being corrupted somehow, or your compiler is not generating<br>proper code, or there's a demon in your phone that's
 playing tricks on you!<br>But this is seriously a weird issue you're having and I have no idea how to even<br>begin to fix it.<br>If you get any more info/details on the cause, let me know, I'll give it another<br>look.<br><br>Good luck!<br>Youness.<br><br><br><br><br><br><br>On 08/16/2012 04:18 AM, ly tran wrote:<br>> Hi,<br>> <br>> Here is my debug result:<br>> In file: conncheck.c, function conn_check_send(), the segmentation occur at line<br>> buffer_len = stun_usage_ice_conncheck_create (&agent->stun_agent,<br>>         &pair->stun_message, pair->stun_buffer, sizeof(pair->stun_buffer),<br>>         uname, uname_len, password, password_len,<br>>         cand_use, controlling, priority,<br>>         agent->tie_breaker,<br>>         pair->foundation,<br>>        
 agent_to_ice_compatibility (agent));<br>> I checked that &pair->stun_message is null and step into this function to follow<br>> this variable. It's always null until segmentation.<br>> <br>> Please refer backtrace in attachment for more details.<br>> <br>> Thanks<br>> --------------------------------------------------------------------------------<br>> *From:* Youness Alaoui <<a ymailto="mailto:youness.alaoui@collabora.co.uk" href="mailto:youness.alaoui@collabora.co.uk">youness.alaoui@collabora.co.uk</a>><br>> *To:* <a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>> *Sent:* Wednesday, August 15, 2012 9:04 PM<br>> *Subject:* Re: [Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9)<br>> <br>> Hi,<br>> <br>> Could you provide a gdb backtrace with "bt full" so I can look into what's<br>> causing it exactly?<br>>
 <br>> Thanks,<br>> Youness<br>> <br>> On 08/15/2012 05:56 AM, ly tran wrote:<br>>> Hi,<br>>><br>>> I use libnice to make video call using SIP (sofia-sip) signalling protocol.<br>>> I used sofsip_cli example in sofia-sip-1.12.11.<br>>> I can make successfull video call in x86 (Ubuntu dekstop).<br>>> But when I compile and run on ARM (Nokia N9), I got the following segmentation<br>>> fault at: nice_agent_set_remote_candidates() function<br>>> Is there anybody have the same problem ?<br>>><br>>> ** Message: parsing SDP:<br>>> v=0<br>>> m=video 32931 RTP/AVP 98<br>>> c=IN IP4 192.168.2.15<br>>> a=rtpmap:98 theora/90000<br>>> a=candidate:1 1 UDP 2013266431 192.168.2.15 32931 typ host<br>>> a=candidate:2 1 UDP 2013266431 169.254.41.172 48865 typ host<br>>> a=candidate:1 2 UDP 2013266430 192.168.2.15 57849 typ host<br>>> a=candidate:2 2 UDP
 2013266430 169.254.41.172 43299 typ host<br>>> a=ice-pwd:sIX8Lqas8Lk1TSgIBboFST<br>>> a=ice-ufrag:owAy<br>>> a=rtcp:57849<br>>><br>>> ---<br>>> ** Message: priv_refresh_nice aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa<br>>> ** Message: priv_set_remote_v_sdp_candidates<br>>> ** (sofsip_cli:1356): DEBUG: Found ice-ufrag:cyES<br>>> ** (sofsip_cli:1356): DEBUG: Found ice-pwd:mYErzMCqTWU+2vZJAQ8uuK<br>>> ** Message: Remote does not support ICE, falling back to non-ICE mode.<br>>> ** Message: nice_agent_set_remote_candidates START<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8: set_remote_candidates 1 1<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : Adding remote candidate with<br>>> addr [192.168.2.15]:33462 for s1/c1. U/P '(null)'/'(null)' prio: 1<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : creating new pair 0xf3000<br>> state 5<br>>>
 (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : added a new conncheck 0xf3000<br>>> with foundation of '1:1' to list 1.<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : stream 1 component 1<br>>> STATE-CHANGE 1 -> 2.<br>>> ** Message: priv_cb_component_state_changed: stream_id=1, component_id=1,<br>>> state=2, self=0xbfc10<br>>> ** Message: rtp comp 1, rtcp com 2, ready 4, disconnected 0 failed 5<br>>> ** Message: goes here<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : creating new pair 0x1030b0<br>> state 5<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : added a new conncheck 0x1030b0<br>>> with foundation of '2:1' to list 1.<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : Pair 0xf3000 with s/c-id 1/1<br>>> (1:1) unfrozen.<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : pair 0xf3000 state WAITING<br>>> (sofsip_cli:1356):
 libnice-DEBUG: Agent 0xc19a8 : priv_conn_check_unfreeze_next<br>>> returned 1<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : pair 0xf3000 state IN_PROGRESS<br>>> (sofsip_cli:1356): libnice-DEBUG: Agent 0xc19a8 : STUN-CC REQ to<br>>> '192.168.2.15:33462', socket=11, pair=1:1 (c-id:1), tie=2663607996370330830,<br>>> username='cyES:owAy' (9), password='mYErzMCqTWU+2vZJAQ8uuK' (22),<br>>> priority=1845494271.<br>>> Segmentation fault<br>>><br>>><br>>> _______________________________________________<br>>> nice mailing list<br>>> <a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> <mailto:<a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a>><br>>> <a href="http://lists.freedesktop.org/mailman/listinfo/nice"
 target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>> <br>> <br>> <br>> _______________________________________________<br>> nice mailing list<br>> <a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> <mailto:<a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a>><br>> <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br>> <br>> <br>> <br>> <br>> _______________________________________________<br>> nice mailing list<br>> <a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br>> <a href="http://lists.freedesktop.org/mailman/listinfo/nice"
 target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br><br><br><br>_______________________________________________<br>nice mailing list<br><a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a><br><a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a><br><br><br> </div> </div>  </div></body></html>