<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div>Hi,</div><div> </div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial, helvetica, sans-serif; background-color: transparent; font-style: normal; ">My solution is rename stun_message_length() on libnice.</div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: arial, helvetica, sans-serif; background-color: transparent; font-style: normal; ">My application can works now.</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="font-family: arial, helvetica, sans-serif; font-size: 12pt; "> <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: Saturday, September 1, 2012 1:09 AM Subject: Re: [Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9) </div> Oh I see, now it makes sense!. Thanks and good job on finding that, that's a very tricky situation. I don't know about sofia-sip, but libnice exports that function as part of its API, so it has to be named that way and it has to be an exportable symbol. I suppose the same for sofia-sip, so I'm not sure the best solution of fixing that would be. There might be some compiler option or at least a way to make sure that all functions within libnice.so are linked to the right internal function. Let me know if you find a way to work around this. thanks On 08/31/2012 12:40 PM, ly tran wrote: > Hi, > > Problem cleared. > My program used sofia-sip and libnice library. But both sofia-sip and libnice > have stun_message_length () function, so it's my problem. > My program always link to stun_message_length() of sofia-sip instead of libnice. > > Thanks for your support. > -------------------------------------------------------------------------------- > *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:* ly tran <<a ymailto="mailto:congly85@yahoo.com" href="mailto:congly85@yahoo.com">congly85@yahoo.com</a>> > *Cc:* "<a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a>" <<a ymailto="mailto:nice@lists.freedesktop.org" href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a>> > *Sent:* Tuesday, August 28, 2012 11:26 PM > *Subject:* Re: [Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9) > > 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> > <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>>; > <a ymailto="mailto:congly85@yahoo.com" href="mailto:congly85@yahoo.com">congly85@yahoo.com</a> <mailto:<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>> >> <mailto:<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>> > <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>>> >>> *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>>> >> <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> <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>>> >> <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> <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>> > <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> <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a> </div> </div> </div></body></html>