[Olsr-dev] olsrd-tip burns cpu,..

L. Aaron Kaplan (spam-protected)
Wed Dec 10 11:41:43 CET 2008

Thanks for stresstesting it  so much! Really cool work! :))
(we might call this the month of stress induced crashes if you continue
like that hehe)

One thing that came to my mind is that you could use gprof to get a clue
where it consumes so much CPU.
In case you dont' know it, I will show you off list. Pretty cool tool
BTW. Maybe you know it already ?
(I you can do the same with valgrind of course)


Markus Kittenberger wrote:
> Today(Yesterday) i found olsrd consuming "all" the cpu for about 10 hours
> so i investigated,..
> after restarting oslr everything is was fine until i fired up a
> interface (which has been down at oslr start) 
> or if start olsr on a non empty routing table (routes from a previous
> olsr crash, or kill), and same will happen within 1-2 minutes, without
> any ifup or down (neither by me nor by anyone/thing else)
> i tried travelling back the changes of the last days, but couldn`t
> track down when it started for long, as older version segfault on my
> ifup testcase, and newer versions burn the cpu,..
> later i found out that starting olsrd on a filled table causes the
> same,.. (cpu burning, and crashing of older version)
> when loggin olsrd -d 9 the last entries always happen while inserting
> removing kernel routes
> i have also core dumpes of an still running and cpu burning olsrd (of
> http://gredler.at/hg/olsrd/rev/70f18097ab12 which seem s the "oldest"
> burn affected version)
> and its easy reproduceable on devVserver,.. (maybe everywhere i
> haven`t tried somewhere else ...)
> but i dont`think the problem was invented in this version, as under
> same setup i assume a bit older version will just crash very soon when
> they start burning,..
> Markus
> ----
> and heres my list of tested versions, and soem of my notes regardign
> the problems i found
> http://gredler.at/hg/olsrd/rev/3cfdfdb37ece
> -nofork fails, testing wihtout gdb, crashes after ifup, burns cpu on
> devVserver (without interfaces all interfaces always up)
> --
> http://gredler.at/hg/olsrd/rev/0c9cde393829
> various config options fail, no further testing
> --
> http://gredler.at/hg/olsrd/rev/ab7a5ece594c
> burns cpu, after ifup, burns when started with an down interface,
> burns on devVsrv (prefilled table?)
> --
> http://gredler.at/hg/olsrd/rev/70f18097ab12  (34 b) 
> burns after ifup, burns anyway on devVsrv? (within 2-3 minutes with
> prefilled table) (quite stable without)
> --
> http://gredler.at/hg/olsrd/rev/ea80a11d61ef (35 replace)
> doesn`t compile,..
> --
> http://gredler.at/hg/olsrd/rev/d9c2226cb81a (36)
> segfaults usually on a single ifudown, 10min stable on stable
> interfaces and emtpy table,..
> --
> http://gredler.at/hg/olsrd/file/71c35e16799d (37)
> 50 % ok, 50 % segfaults on single ifup or down, sometimes crashes
> without reason,..  
> ---
> http://gredler.at/hg/olsrd/rev/338f9b4540da (42)
> <http://gredler.at/hg/olsrd/rev/338f9b4540da>
> 50 % ok, 50 % segfaults on a single ifdown, crashes without reason,..
> (or on a prefilled kernel table)
> anyway i commited my last patch,
> http://gredler.at/hg/olsrd/rev/3c1cb506bc10
> unfortunately i can`t really test it properly, as olsrd-tip fails the
> most suitable testcase for this pach (handling an ifdown (and an ifup)
> properly) in all versions i mentioned in this mail
> but at least i tested whether it removes the links of an interface,
> and not all links of interfaces with same ip adresses,
> but if you ifup this interface again olsrd starts to burn a hole into
> ..., like the versions before,..
> Markus
> p.s. (written in the middle of testing without any clue what affects
> the problems) (-;
> for the moment i consider the tip quite and 0.5.6x unuseable for
> routers (like most of mine) having not only "always up" interfaces,.. )-;
> so my real goal, tracking down the reasons for inconsistent kernel and
> olsr routing tables, has too wait until olsr is more stable while
> running on dynamic interfaces, which me and funkfeuer need anyway (ok
> we could change our needs, but i prefer changin olsrd (-;), and serve
> as a good starting testcase for above goal,..
> i will continue investigating, and testing, this an related issues,
> but hmm .. i could imagine a better start into olsrd for me,.. (-;
> anyhow i have to compliment henning and hannes, for their patches and
> support during the last days, but hmm i guess there`s a lot more to do (-;
> ok i better stop whining now!  (-;  ;-)

More information about the Olsr-dev mailing list