lighttpd, uid 80: exited on signal 11

[Dan Lukes]

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