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