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

[Dan Lukes]

Miroslav Lachman wrote on 02/29/16 12:40:
> Zkusil jsem to se 4.7

> Core was generated by 'dns-terror'.
> Program terminated with signal 11, Segmentation fault.

> Loaded symbols for /usr/local/lib/gcc47/libstdc++.so.6
> Loaded symbols for /usr/lib/libc++.so.1

Tohle vypada smrtelne. Do jednoho binaru se prilinkovavaji c++ knihovny 
portovyho GCC a soucasne systemovy c++ knihovny,

To je asi jako delat taborak na burty ve skladu benzinu.

Zrejme "USE_GCC" nezvladlo Make system toho zdrojaku presvedcit aby 
vsude pouzilo GCC, cast prekladala nebo linkovala systemovym compilerem, 
a to by byl zazrak, kdyby to fungovalo.

> (gdb) bt

To se nevyhrabalo ani z uvodni inicializace. Takrka jiste jsme jeste 
nedosli ani k uzivatelovu main(). Coz ale s ohledem a avyse uvedene 
neprekvapi.

> I kdyz i tak mi prijde ten seznam zavislosti jako obludne velky balik

Kdyz on je portovy system zavislosti na tohle trochu hrubej nastroj. 
Zavisej pouze cely baliky na jinejch balicich. Nejde tam rict, celej 
balik zavisi na A..Z, ale pokud pouzijes jen tyhle dve knihovny, tak ty 
zavisej jen na 1-3.

Musel bys ten balik riznout - na cast, ktera vyrobi sdileny (runtime 
potrebny) knihovny a cast, ktera by obsahovala zbytek. Prelozene 
aplikace by pak zavisely jen a tom runtime baliku.

>>> No,porad's to jeste nezkusil zkompilovat s -O optimalizacema. ;-)
> Zmena je v tom, ze ted to hodi "Bus error (core dumped)", zatim co predtim to bylo "Segmentation fault (core dumped)"

> #4  0x00000000004021de in fatal_errno (what=0x7fffffffe3f8 "\020",
>     errnoval=<value optimized out>) at dns-terror.cc:129


Ona ta chyba nastava taky na jinym miste. dns-terror.cc:129 je
   fprintf(stderr, "%s: fatal error: %s: %s\n", program_name, what, 
strerror(errnoval));

Jenze v bt by melo bejt videt kdo/odkud tu fatal_errno volal - a neni.

Zrejem je, ze to ej nova chyba. Smusny je, ze nevime ani, jestli k ni 
doslo pred tim, nez by se kod dostal do kritickeho mista predchozi chybu 
nebo potom. Takze nevime jestli jsme jednu chybu zamenili za druhou, 
nebo "jen" pridali dalsi problem.

No, to ej uz opravdu na autora kodu. At tam nejak vyresi ten c++ 
konstrukt, co si na nej prekladac stezuje jako an nestandardni a nemelo 
by ti to (v puvodnim prekladu a s puvodnimi optiony) padat - teda, pokud 
tam pozdeji nebud eneco dalsiho.

Dan