[Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9)
ly tran
congly85 at yahoo.com
Tue Aug 28 04:31:52 PDT 2012
Hi,
If I didn't call function stun_fingerprint() (comment ) at stun_agent_validate() in stunagent.c, I can establish call in 20 seconds.
Can you explain the function stun_fingerprint()
________________________________
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>
> *To:* 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>
>> 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
_______________________________________________
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/20120828/6d2145e3/attachment-0001.html>
More information about the nice
mailing list