[Nice] Segmentation fault with libnice-0.1.2 on ARM ( Nokia N9)

Youness Alaoui youness.alaoui at collabora.co.uk
Fri Aug 31 11:09:36 PDT 2012 

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 <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
> <mailto:youness.alaoui at collabora.co.uk>>
>> *To:* nice at lists.freedesktop.org <mailto:nice at lists.freedesktop.org>;
> congly85 at yahoo.com <mailto: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>
>> <mailto: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>
> <mailto: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>>
>> <mailto: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>>
>> <mailto: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>
> <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
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20120831/ae2948bd/attachment.pgp>

More information about the nice mailing list