dns-terror (fastresolve-2.10_5) core dump na FreeBSD 10.x

[Dan Lukes]

On 13.1.2016 13:05, Miroslav Lachman wrote:
> Dlouha leta pouzivam prikaz dns-terror na resolvovani IP adres v log

> Stejne chovani je na 10.1 i 10.2
> +pid 62102 (dns-terror), uid 0: exited on signal 10 (core dumped)

To se stane snadno - staci aby byla aplikace neportabilne napsana a o 
svem okoli predpokladala veci, ktere v konkretnim prostredi neplati, a 
nestesti je na svete.

SIGBUS je obvykle znamka toho, ze se aplikace pokousela sahnout na 
pamet, na kterou sahat nema narok (nebo ktera dokonce vubec neexistuje).

K tomu staci malo - neoverit, ze nejaka funkce, ktera ma vracet pointer 
za nekterych okolnosti vrati NULL (staci treba prosta alokace pameti), 
nespravne predpokladat velikosty typu promennych a bohorovne ukladat 
pointer na cosi do int pripadne obracene a tak ...

> Zkousel jsem i truss, ale to uz se dostavam na tenky led, kde moc nevim,
> co delam a co mam videt.

> gettimeofday({1445175729.664378 },0x0)           = 0 (0x0)
> recvfrom(3,0x7fffffffe060,512,0x0,0x7fffffffe000,0x7fffffffe01c) ERR#35
> 'Resource temporarily unavailable'
> stat("/usr/share/nls/C/libc.cat",0x7fffffffded0) ERR#2 'No such file or
> directory'
> stat("/usr/share/nls/libc/C",0x7fffffffded0)     ERR#2 'No such file or
> directory'
> stat("/usr/local/share/nls/C/libc.cat",0x7fffffffded0) ERR#2 'No such
> file or directory'
> stat("/usr/local/share/nls/libc/C",0x7fffffffded0) ERR#2 'No such file
> or directory'
> SIGNAL 10 (SIGBUS)

No, ja sice truss neznam, ale tyhle informace jsou dost univerzalni. pro 
ucely tveho dotazu ale nejsou napovedou dostatecnou. Vime, ze kod volal 
gettimeofday (a to dopadlo uspesne), pak zkousel prijmout 512B sitovych 
dat z deskriptoru 3 bez flagu, coz skoncilo EAGAIN. Nasledne kod shanel, 
z nazvu souboru soude, po message catalogu, coz je pravdepdobne soucast 
funkce catopen(). Ta se vola v ramci strerror(), jejiz volani po 
recvfrom, ktere skoncilo chybou neni neocekavatelne.

Potud to vypada jako nadejna cesta.

Zda se tedy byt pravdepodobne, ze chyba je bud' uvnitr libc v ramci 
funkce strerror, nebo v aplikace zhavaruje na tom co ji strerror vratil. 
Ale porad je to hypoteza, ktera nemusi byt spravna.

Cimz se dostavame k tomu, ze truss na tohle neni nejstastnejsi, jakkoli 
pro zakladni orientaci poslouzil celkem dobre (stejne dobre me ale mozna 
zavedl na uplne slepou cestu).

Z truss se nepozna ci dany kod je - sekvence kodu, kterou shora 
naznacuju tak muze byt v libc, primo v aplikaci, v nejake jine knihovne, 
kterou aplikace pouziva (treba adns).

Potrebujes aplikaci prelozenou s debugovacima informacema (preklad i 
linkovani s -g a zadne optimalizace, tedy -O0) - a nasledne se pak 
proste podivas na coredump, ktery to pri padu vytvori, ktery ti ukaze na 
kterem radku jakeho zdrojaku kod byl, kdyz to zbuchlo. Hned uvodis, 
jestli uvnitr libc nebo nekde v aplikaci.

> Jde zkompilovat ten port s nejakyma debug options_

Muzes zkusit kompilovat s WITH_DEBUG, k tomu pripadne nastavit 
DEBUG_FLAGS=-g

Muze se ale stat, ze to u konkretniho portu neudela to co cekas. Pak by 
bylo nutne si kod prelozit sam - tedy nezavisle na portovem systemu.

Rec samozrejme neni o samotnem dns-terror, ale o kodu kazde knihovny, 
kterou tento pouziva. I kdyz neni nutne hned prekladat jako debugovaci 
vsechno. Muzes zacit hlavnim portem a kdyz z coredumpu vyplyne, ze k 
padu doslo uvnitr kodu nejake knihovny, tak prelozis jeste tu a opakujes.

Dan