[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zebra
Subject:    [zebra 5914] Re: [PATCH] bug in thread.c ?!
From:       Kunihiro Ishiguro <kunihiro () zebra ! org>
Date:       2000-11-29 1:49:03
[Download RAW message or body]

> Of course. The situation above is not only theoretically possible,
>but it actually happens some times and cause "strange" core dumps.
>
> I can describe you one that we've caught here recently:
> Two events happen simultaneously:
>   1) we get message from zebra that interface eth0 is down.
>   2) hello timer of interface eth0 expired.
>
>thread_fetch adds both of this threads to event list and executes
>first one (eth0 is down).  ospf_if_down is called. ospf_if_down
>schedule ISM_InterfaceDown event, calls ospf_if_stream_unset on eth0,
>close file descriptor and exits. The ISM_InterfaceDown is added after
>hello timer on event list thus next thread that is executed is hello
>timer (and not ISM_InterfaceDown as ospf expects). Hello timer tries
>to use stream from eth0, but stream is unset already and ospf
>coredumps :(. But If ISM_InterfaceDown will be executed first it will
>cancel hello timer and ospf will work OK.
>
> There are plenty of such race conditions through the ospf code,
>that's why I've got impression that events are expected to be executed
>before any other thread, but this is not true for current scheduler
>implementation.

Now I understand the situation.  I've just committed the patch to the
CVS repository.
-- 
Kunihiro Ishiguro

[prev in list] [next in list] [prev in thread] [next in thread]