<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div style="font-size: 12pt; ">Hi,</div><div style="font-size: 16px; color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; background-color: transparent; font-style: normal; "> </div><div style="font-size: 16px; color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; background-color: transparent; font-style: normal; ">Problem cleared.</div><div style="color: rgb(0, 0, 0); font-family: arial, helvetica, sans-serif; background-color: transparent; font-style: normal; ">My program used sofia-sip and libnice library. But both sofia-sip and libnice have stun_message_length () function, so it's my problem.</div><div style="color: rgb(69, 69, 69); font-family: Arial, Helvetica, sans-serif; background-color: transparent; font-style: normal; ">My program always link to stun_message_length() of sofia-sip instead of libnice.</div><div style="color: rgb(69, 69, 69); font-family: Arial, Helvetica, sans-serif; background-color: transparent; font-style: normal; "> </div><div style="font-size: 12pt; ">Thanks for your support.</div> <div style="font-size: 12pt; font-family: arial, helvetica, sans-serif; "> <div style="font-family: 'times new roman', 'new york', times, serif; font-size: 12pt; "> <div dir="ltr"> <hr size="1"> From: Youness Alaoui <youness.alaoui@collabora.co.uk> To: ly tran <congly85@yahoo.com> Cc: "nice@lists.freedesktop.org" <nice@lists.freedesktop.org> Sent: Tuesday, August 28, 2012 11:26 PM Subject: Re: [Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9) </div> That makes no sense : The stun_sha1 function is called with the stun_message_length() return value as argumnent : stun_sha1 (msg->buffer, stun_message_length (msg), stun_message_length (msg) - minus, ptr, key, key_len, TRUE); So there is no way that stun_message_length doesn't get called... or that it returns -1 without calling it. Maybe that's your problem though.. maybe your ARM compiler is somehow optimizing that function out and puts -1 instead? On 08/28/2012 04:05 AM, ly tran wrote: > Hi, > > 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. > > I debug and know that libnice never goes into stun_message_length() function. > It's always return -1. > > -------------------------------------------------------------------------------- > *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>; <a ymailto="mailto:congly85@yahoo.com" href="mailto:congly85@yahoo.com">congly85@yahoo.com</a> > *Sent:* Friday, August 17, 2012 3:53 AM > *Subject:* Re: [Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9) > > 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> > <mailto:<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> <mailto:<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>> > <mailto:<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>> > <mailto:<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> <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> </div> </div> </div></body></html>