[Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9)
ly tran
congly85 at yahoo.com
Fri Aug 31 09:40:38 PDT 2012
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 <youness.alaoui at collabora.co.uk>
To: ly tran <congly85 at yahoo.com>
Cc: "nice at lists.freedesktop.org" <nice at 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)
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 <youness.alaoui at collabora.co.uk>
> *To:* nice at lists.freedesktop.org; congly85 at yahoo.com
> *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 <youness.alaoui at collabora.co.uk
> <mailto:youness.alaoui at collabora.co.uk>>
>> *To:* nice at lists.freedesktop.org <mailto:nice at lists.freedesktop.org>
>> *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
>>> nice at lists.freedesktop.org <mailto:nice at lists.freedesktop.org>
> <mailto:nice at lists.freedesktop.org <mailto:nice at lists.freedesktop.org>>
>>> http://lists.freedesktop.org/mailman/listinfo/nice
>>
>>
>>
>> _______________________________________________
>> nice mailing list
>> nice at lists.freedesktop.org <mailto:nice at lists.freedesktop.org>
> <mailto:nice at lists.freedesktop.org <mailto:nice at lists.freedesktop.org>>
>> http://lists.freedesktop.org/mailman/listinfo/nice
>>
>>
>>
>>
>> _______________________________________________
>> nice mailing list
>> nice at lists.freedesktop.org <mailto:nice at lists.freedesktop.org>
>> http://lists.freedesktop.org/mailman/listinfo/nice
>
>
>
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org <mailto:nice at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/nice
>
>
_______________________________________________
nice mailing list
nice at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20120831/29ddf736/attachment-0001.html>
More information about the nice
mailing list