On 12.4.2019 12:32, Miroslav Lachman wrote:
Na serveru se v poslednich tydnech nic neupravovalo / nainstalovalo a
dneska od 5 hodin rano se deje tohle segfaultovani s zeleznou
pravidelnosti. Kdykoliv Lighttpd spustim a prijde request na
/server-status, tak to segfaultne.
Posledne, kdyz se mi tohle delo, tak zabralo to, ze jsem udelal "pkg
upgrade -f lighttpd", cimz doslo k reinstalaci na identickou verzi
(identickou instanci baliku z vlastniho repozitare).
Jakou to s tim muze mit souvislost nemam tuseni.
Napada nekoho, cim to muze byt a jak to vyresit?
SIGSEGV/SEGV_MAPERR je dusledek exception PAGEFAULT vznikle v samotnem
procesoru. Jde o pokus o pristup k takove linearni pametove adrese,
ktera efektivne neexistuje (nema mapovani ani do fyzicke poameti ani do
swapu).
Nejcasteji jde o dereferenci neinicializovane promenne (tedy nahodneho
cisla) pripadne o dereferenci hodnoty sice kdysi inicializovane, pozdeji
vsak al enahodne prepsane (vlivem nejake jine chyby v kodu).
To je ale jen obecna analyza, k nalezeni konkretniho problemu ti to moc
nepomuze.
Nastesti - deterministicky se vyskytujici chyba je vlastne ten nejlepsi
scenar. To se totiz da ladit.
Normalne bych rekl - pust' to pod gdb (idealne jako single-thread a na
popredi, lighttpd neznam, tak nevim jak to udelat, u Apache jsou to
optiony prikazove radky pri spusteni), vyvolej spadnuti, ono to skonci
an prikazove radce debuggeru a tam si prikazem 'bt' nech ukazat "strom
zanoreni" - tedy pres jake funkce se kod dostal do mista padu.
Ale kdyz ti to pada jen pri tom konkretnim requestu, muzeme si dovolit
hadat, ze problem nastava v mod_status.c a zkusit rovnou zkratku.
Hlavni funkce, ktera generuje vlastni vystup, v mod_status je
mod_status_handle_server_status()
Takze spustit pod debuggerem, idealne znovu jako
single-thread/foreground, dat breakpoint na tuhel funkci a zkusit
vyvolat pad. Debugger ti vyleze v okamziku vstupu do tehle funkce, a tam
krokovat radek po radku (neni jich zas tolik) se zanorovanim se do
podfunkci - a cekat, kdy to buchne. No a podle toho kde to buchne se uvidi.
Nesliboval jsem, ze to bude jednoduchy - rikal jsem, ze deterministicka
chyba je ten nejlepsi scenar.
Zapomel jsem rict, ze to bude snazsi, kdyz si lighttpd prelozis s
debugovacimi informacemi a debugger bud emit pristup i ke zdrojakum -
pak ti to bude pruchod ukazovat "po radcich" zdrojoveho kodu.
Dan
Mam tu zaznam z truss
kevent(14,0x0,0,{ 15,EVFILT_READ,0x0,0,0x18d,0x0 },2049,{ 1.000000000 })
= 1 (0x1)
ioctl(15,FIONREAD,0x7fffffffa794) = 0 (0x0)
read(15,"GET /server-status HT"...,4095) = 397 (0x18d)
SIGNAL 11 (SIGSEGV) code=SEGV_MAPERR trapno=12 addr=0x0
process killed, signal = 11
A stejny zaznam o par minut pozdeji z ktrace
62872 lighttpd GIO fd 15 read 423 bytes
"GET /server-status HTTP/1.1\r
Host: XXX.YYY.ZZZ\r
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; aaaa bbbb ccccc\r
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r
Accept-Language: cs,cs-CZ;q=0.8,en-US;q=0.5,en;q=0.3\r
Accept-Encoding: gzip, deflate\r
DNT: 1\r
Connection: keep-alive\r
Upgrade-Insecure-Requests: 1\r
Cache-Control: max-age=0\r
\r
"
62872 lighttpd RET read 423/0x1a7
62872 lighttpd PSIG SIGSEGV SIG_DFL code=SEGV_MAPERR
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
