[Olsr-dev] OLSRv2 Segfault

[Henning Rogge]

Thank you for the GDB log,

it seems that the Hello generation fails... I have to look more closely
into the problem when I am back at work next week, but I committed your
patch as a hotfix until I know what the hell is going on.

@Syed Salman Haider Rizvi:
I have also added a patch to OLSRD2 that allows to switch off the linkspeed
part of the ETT plugin, downgrading it to ETX. So you might also want to
have a look into the most recent version.

Henning Rogge

On Mon, Dec 30, 2013 at 4:50 AM, Vigneswaran R <(spam-protected)> wrote:

> On 12/28/2013 12:17 AM, Henning Rogge wrote:
>
>> Hi,
>>
>> thank you for the bugreport, I would like to dig a little bit deeper
>> into this problem (maybe writing an automatic test-case afterwards).
>>
>> Can you post the whole stacktrace from GDB first? That would allow to
>> identify if the error happens during the creation of a Hello or a TC.
>>
>
> Please find the GDB log attached. Thanks.
>
> vignesh
>
>
>  Henning Rogge
>>
>> On Fri, Dec 27, 2013 at 11:10 AM, Vigneswaran R <(spam-protected)>
>> wrote:
>>
>>> Hello,
>>>
>>> I am running olsrd2 on a few (qemu) virtual machines. On one of the
>>> virtual
>>> machines, olsrd2 segfaults within a few seconds. I am invoking OLSRd2 in
>>> the
>>> following manner,
>>>
>>>      ./olsrd2 --set interface[eth0].bindto=10.0.0.0/8 --set
>>> interface[eth1].bindto=10.0.0.0/8 --set interface[eth2].bindto=10.0.0.
>>> 0/8
>>>
>>> Traced the error using gdb to some extent. Please see the following patch
>>> for context.
>>>
>>> In general, addr_start->_block_end becomes NULL just before exiting from
>>> the
>>> do..while loop. However, in some cases, addr_start->_block_end becomes
>>> NULL
>>> before the do..while loop meeting the exit criteria (addr_end ==
>>> last_addr).
>>> So, the loop continues and trying to de-reference NULL pointer causing
>>> segfault.
>>>
>>> --- a/oonf_api/src-api/rfc5444/rfc5444_msg_generator.c    2013-12-19
>>> 18:27:48.471467295 +0530
>>> +++ b/oonf_api/src-api/rfc5444/rfc5444_msg_generator.c    2013-12-27
>>> 14:15:14.000000000 +0530
>>> @@ -1180,7 +1180,7 @@
>>>       tlvblock_length[0] = (ptr - tlvblock_length - 2) >> 8;
>>>       tlvblock_length[1] = (ptr - tlvblock_length - 2) & 255;
>>>       addr_start = list_next_element(addr_end, _addr_node);
>>> -  } while (addr_end != last_addr);
>>> +  } while (addr_end != last_addr && addr_start->_block_end != NULL);
>>>
>>>     /* store size of address(tlv) data */
>>>     msg->_bin_addr_size = ptr - start;
>>>
>>>
>>> I am using the latest oonf_api (last commit:
>>> 2355db6a460abe10cc7096842b3b10686c68012c) and olsrd2 (last commit:
>>> 23051120419372a175ddb08fa8a3bb8d7d709f1e) repositories.
>>>
>>> The Interface details are,
>>>
>>> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
>>>      link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>>>      inet 127.0.0.1/8 scope host lo
>>>      inet6 ::1/128 scope host
>>>         valid_lft forever preferred_lft forever
>>> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>>> state
>>> UP qlen 1000
>>>      link/ether de:ad:be:ef:5a:38 brd ff:ff:ff:ff:ff:ff
>>>      inet 10.5.11.1/8 brd 10.255.255.255 scope global eth0
>>>      inet6 fe80::dcad:beff:feef:5a38/64 scope link
>>>         valid_lft forever preferred_lft forever
>>> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>>> state
>>> UP qlen 1000
>>>      link/ether de:ad:be:ef:0d:2f brd ff:ff:ff:ff:ff:ff
>>>      inet 10.5.11.2/8 brd 10.255.255.255 scope global eth1
>>>      inet6 fe80::dcad:beff:feef:d2f/64 scope link
>>>         valid_lft forever preferred_lft forever
>>> 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>>> state
>>> UP qlen 1000
>>>      link/ether de:ad:be:ef:5a:39 brd ff:ff:ff:ff:ff:ff
>>>      inet 10.5.11.3/8 brd 10.255.255.255 scope global eth2
>>>      inet6 fe80::dcad:beff:feef:5a39/64 scope link
>>>         valid_lft forever preferred_lft forever
>>>
>>>
>>> Regards,
>>> Vignesh
>>>
>>> --
>>> Olsr-dev mailing list
>>> (spam-protected)
>>> https://lists.olsr.org/mailman/listinfo/olsr-dev
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20131230/43bb7577/attachment.html>