[Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9)
Youness Alaoui
youness.alaoui at collabora.co.uk
Fri Aug 17 06:33:34 PDT 2012
Hi,
Yes, the password is the remote and the username is remote:local, that's normal.
I noticed the wrong uname/length, but that's why I said the stack is corrupted.
See the stack trace :
#6 0x3ac03adc in conn_check_send (agent=0xc19a8, pair=0xf5598) at conncheck.c:1635
priority = 97240
uname =
"whhh:BQA9\000\000\000\004\000\000\000l\240\231\256\\\257QM\000\000\000\000<\237\231\256\020\374\v\000\200\067\001\000\240u\001\000\001\000\000\000\002\000\000\000\004\000\000\000\000\000\000\000\005\000\000\000P\371;M\000\274~f\000\000\000\000\314\066\001\000\030\v\004\000\200\251\004\000\250\031\f\000\200\251\0---Type
<return> to continue, or q <return> to quit---
04\000\000\000\000\000\004\000\000\000l\240\231\256\004\000\000\000\250\031\f\000\224\237\231\256\000\000\000\000\270\257\300:\370x\001\000\001\000\000\000\020\374\v\000\000\000\000\000HV\020\000\340\372\016\000\250\031\f\000X\373\016\000\000\000\000\000\001\000\000\000\370\346\f\000d@\300:\002\000\000 at 8\v\004\000\020t\002\000\026\000\000\000\250\031\f\000\360\235\f\000\250\031\f\000\004\000\000\000\000\000\000\000l\240\231\256
\266\n\000\000\000\000\000<\234\301:\360\233\301:
\266\n\000\000\000\000\000\260\216'M$\233\301:l\240\231\256\004\203:M\004\061\064\066"...
uname_len = 1004972
password = 0xca107 "PMRQdCfvaopURktQh4vzgK"
password_len = 1004972
That's in conn_check_send, and just before it calls the
stun_usage_ice_conncheck_create it prints uname_len/password_len and they are
correct :
(sofsip_cli:2553): libnice-DEBUG: Agent 0xc19a8 : STUN-CC REQ to
'192.168.1.46:37427', socket=15, pair=1:1 (c-id:1), tie=10836474145881329082,
username='whhh:BQA9' (9), password='PMRQdCfvaopURktQh4vzgK' (22),
priority=1845494271.
Both uname_len and password_len are not modified by conn_check_send, so this
means that the stack was corrupted. If the stack is corrupted, then it's hard to
believe its content because you don't know what is real and what got corrupted.
Yes, I have an N9, so I can test this myself and see if I can debug it. But I
can't guarantee anything, I'm not sure I'll have any free time to be looking
that deeply into this problem.
Youness.
On 08/17/2012 03:38 AM, ly tran wrote:
> Hi,
>
> 1. I didn't change any thing in libnice and my application run well on x86 computer.
> 2. Is this debug line is normal ?
> (sofsip_cli:1573): libnice-DEBUG: Agent 0xc1610 : STUN-CC REQ to
> '192.168.1.43:40183', socket=15, pair=1:1 (c-id:1), tie=10819118275753794247,
> username='GbRO:fHIZ' (9), password='EQTzkej5Ba4EGqMjCRCMMJ' (22),
> priority=1845494271.
> I saw that username here is "remote_username:local_username" ( length = 9) but
> password has only remote password.
>
> If this normal, then the problem occur in conn_check_send() function at conncheck.c
> 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));
>
> This function change the username, password and length value.
> The backtrace show difference username, username length, password, password length.
> md5 = "\207\235\f\000\026\000\000\000\377\001\000n\307\332", <incomplete
> sequence \351>
> #6 0x3ac02a7c in conn_check_send (agent=0xc1610, pair=0xf38b8) at conncheck.c:1635
> priority = 97240
> uname =
> "GbRO:fHIZ\000\000\000\004\000\000\000|P\377\256\\/\317L\000\000\000\000LO\377\256\020\370\v\000\200\067\001\000\240u\001\000\001\000\000\000\002\000\000\000\004\000\000\000\000\000\000\000\005\000\000\000Py\263L\000u`\313\000\000\000\000\314\066\001\000@\n\004\000\200\251\004\000\020\026\f\000\200\251\004\000\000\000\000\000\004\000\000\000|P\377\256\004\000\000\000\020\026\f\000\244O\377\256\000\000\000\000X\237\300:\370x\001\000\001\000\000\000\020\370\v\000\000\000\000\000h9\020\000\340\362\016\000\020\026\f\000X\363\016\000\000\000\000\000\001\000\000\000\220\344\f\000\004\060\300:\002\000\000@\270\300\003\000\020t\002\000\026\000\000\000\020\026\f\000p\232\f\000\020\026\f\000\004\000\000\000\000\000\000\000|P\377\256
> \260\n\000\000\000\000\000\300\207\301:t\207\301:
> \260\n\000\000\000\000\000\260\016\237L\250"...
> uname_len = 997580
> password = 0xc9d87 "EQTzkej5Ba4EGqMjCRCMMJ"
> password_len = 997580
>
> If you have N9 device, I will send you the source code problem.
> Thanks
> --------------------------------------------------------------------------------
> *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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20120817/ef2fded1/attachment.pgp>
More information about the nice
mailing list