A critical error when working with POLL and EPOLL?
I maintainer di solito rispondono entro 2 giorni
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 20/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- c, linux
- Ambito
- networking
Direzione di ricerca
Start by reading lib/poller.c around epoll_events() (line ~84) and poller_poll() (line ~180), plus daemon/media_socket.c near line 3120. The issue has had no reply for over a year, so reproduce the trade-off it describes: frozen RTP sessions with EPOLLET versus CPU busy-wakes without it, and check epoll(7) for edge-triggered semantics. Done means the poller keeps sessions alive without uncontrolled wakeups, and the proposed flag changes are either confirmed or replaced.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
In addition to the previous issue.
After adding changes to this source code, the functionality for resetting active_read_events and error_strikes to 0,
the problem was not completely resolved.
There is a suggestion of a critical error in the current implementation of the poller_poll() and epoll_events()
functions.
The EPOLLET flag has been added to the implementation of the epoll_events() function. However, the poller_pool()
function analyzes the polling constants (POLLERR, POLLHUP), which is incorrect. As a result, frozen RTP sessions
appear 10-15 seconds after the call. Removing the EPOLLET solves the problem of hanging, but it leads to CPU
overload (constant uncontrolled wakeups).
What if you tweak the epoll_event() and poller_poll() functions, change the POLL constants to EPOLL, this will lead to the
absence of "frozen sessions", low CPU load, and correct operation with epoll constants.
New version of epoll_events():
return EPOLLHUP | EPOLLERR | EPOLLET | EPOLLRDHUP | EPOLLPRI |
((it->writeable && ii && ii->blocked) ? EPOLLOUT | EPOLLWRNORM | EPOLLWRBAND : 0) |
(it->readable ? EPOLLIN | EPOLLRDNORM | EPOLLRDBAND : 0);
And in the new version of the poller_poll() function, analyze these flags:
...
if (ev->events & (EPOLLERR | EPOLLHUP | EPOLLRDHUP))
it->item.closed(it->item.fd, it->item.obj);
else {
if (ev->events & (EPOLLIN | EPOLLPRI | EPOLLRDNORM | EPOLLRDBAND)) {
if (it->item.readable)
it->item.readable(it->item.fd, it->item.obj);
}
else
if (ev->events & (EPOLLOUT | EPOLLWRNORM | EPOLLWRBAND)) {
mutex_lock(&p->lock);
it->blocked = 0;
ZERO(e);
...
}
...
What do you think it's correct fix or not?
Thanks in advance!
- Lingua principale
- Perl
- Stelle
- 992
- Fork
- 459
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di sipwise/rtpengine
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
I maintainer di solito rispondono entro 2 giorni
-
HTTP/WS worker threads spin forever in `__websocket_write_done()` (`sched_yield` loop) — 100% CPU with `--listen-http`Forse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 15/100
sipwise/rtpengine#2197 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Kernel NULL pointer dereference in target_put() during target deletionForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 38/100
sipwise/rtpengine#2190 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
-
Calls using a third logical interface are silently never written to Redis (breaks keyspace-notification HA)Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
sipwise/rtpengine#2181 · 4 commenti ·
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
sipwise/rtpengine#2162 · 1 commento ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di sipwise/rtpengine
Issue simili
-
Add .gitattributes so share/skel keeps LF on a Windows git checkoutForse già presa @sadhana-s-codez l’ha presa 1 giorno fa. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
PerlDancer/Dancer2#1854 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
major/MySQLTuner-perl#1007 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 69/100
bioconda/bioconda-recipes#70187 ·
I maintainer di solito rispondono entro 2 giorni