[radvd-devel-l] radvd crash with multiple interfaces when 1 interface comes back up
reubenhwk at gmail.com
Wed May 5 12:30:26 EDT 2010
This is happening in the latest from CVS in the timer code? Can you
reproduce this crash in the code I submitted which removes the timers? It
seems like the timers are the source of half the problems submitted to the
mailing list. I stand by removing the timers. Building a poll/select based
solution will dramatically simplify the code and debugging. Please let me
know what guidelines I should follow to get my code integrated into the next
On Tue, May 4, 2010 at 2:20 AM, Pekka Savola <pekkas at netcore.fi> wrote:
> During today's testing I found a similar problem that Teemu fixes last
> When you have multiple interfaces (IgnoreIfMissing=on, and one interface is
> down, when you bring it back up, radvd crashes with a segfault in
> timer.c:152 ("tm->prev->next = tm->next;").
> Interestingly enough, I don't see this happening when running radvd as
> I played around with this a bit, but could not figure out the real root
> cause. I'm tempted to work around this by applying the following
> work-around fix. Anyone else interested in looking into this a bit more?
> On Thu, 27 Aug 2009, Teemu Torma wrote:
>> On Thursday 27 August 2009 15:20:23 Pekka Savola wrote:
>>> Anyone interested and have time to look at this? I'll try to figure
>>> out more when I have a bit more time.
>> I did that yesterday and I have been running the radvd with attached patch
>> which seems to cure the problem.
>> The issue is that when interface comes back up, send_ra will call
>> reload_config which will reset timers for all interfaces. However, the
>> current timer event will continue processing as usual and at the end will
>> reset the current timer. Since reload_config already did that, timer list
>> pointers will be screwed and at least in my case cause an infinite loop.
>> I haven't tried this, but it might suffice to ignore already existing
>> entry in set_timer (i.e, tm->next && tm->prev).
>> I don't know the code well enough to say if this is a good way to deal
>> the issue.
> radvd-devel-l mailing list : radvd-devel-l at litech.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the radvd-devel-l