Open
Description
The olsr respondd provider is currently broken
A crash occurs when it is executed in a fork
In this fork the provider is overriding the uloop global state. not forking would lead to a crash. (supposedly)
The provider does crash in the fork aswell, but did not crash during an execution in debugger once, meaning its just a race condition.
Since its in a fork, its harder to debug and ive just given up at this point
Another thing to note is that olsr1&2 have a hardlimit on concurrent api requests/telnet sessions and 1) those failures would have to be handeled with retries in libolsrdhelper 2) the failures can be reduced by raising the limit to a more appropriate size (as we do many calls per provider)
- figure out if uloop really isnt reenterent or if we just screw it up
- fix race
- fix olsr limits
Metadata
Metadata
Assignees
Labels
No labels