[vz-users] Auswertung Protocol d0 / deamon Absturz

[Thorben Thuermer]

Hallo,

das problem ist dann geklaert:
der resolver in libcurl ist _nicht_ thread-safe.

d.h., wenn zwei threads gleichzeitig einen namen aufloesen, gibt es eine
race-condition die zu dem crash fuehrt.

das ist recht eindeutig ein bug in libcurl...
unter: http://curl.haxx.se/libcurl/features.html
wird angegeben, libcurl sei dann thread-safe, wenn die gethostbyname()
funktion des betriebssystems thead-safe ist,
aber das problem liegt nicht in gethostbyname(), sondern in der benutzung
von alarm() um einen timeout fuer gethostbyname() zu erzwingen.
(related: https://bugzilla.redhat.com/show_bug.cgi?id=539809 ) 

in Eugen's konfiguration tritt das problem vor allem deshalb auf,
weil aus einem meter zwei channels erzeugt werden,
d.h. jedesmal wenn vom meter daten kommen, werden gleichzeitig zwei
middleware-aufrufe gestartet, um die daten der beiden channels zu
uebermitteln, was dann irgendwann das richtige timing fuer die race-condition
liefert und zum crash fuehrt.

der crash tritt seltener auf, wenn man statt "localhost" direkt "127.0.0.1"
fuer den middleware-server angibt, vermutlich weil die aufloesung dann
schneller geht.
(ein externer dns-server ist in beiden faellen nicht involviert,
 da der name im hostsfile steht.)

als fix waehre entweder der bug in libcurl zu beheben...
oder libcurl mit unterstuetzung fuer einen alternativen resolver zu kompilieren:
http://curl.haxx.se/dev/readme-ares.html

ansonsten kann man als workaround libcurl ohne HAVE_ALARM kompilieren
(nach dem ./configure den HAVE_ALARM eintrag in lib/curl_config.h
entfernen oder auskommentieren (nicht 1 durch 0 ersetzen!).
(das hat den nachteil, dass das programm u.U. bei der aufloesung
 haengenbleibt, falls der timeout-mechanismus des betriebssystems
 nicht greift.)

(Eugen: letzteres ist momentan bei dir in /vz/libcurl-7.28.0-prefix bzw
 /vz/curl-7.28.0 implementiert, vzlogger laeuft jetzt seit ueber
 zehn stunden durch.)

- T.

On Sat, 20 Oct 2012 22:41:27 +0200 Thorben Thuermer <r00t at constancy.org> wrote:
> On Sat, 20 Oct 2012 17:32:26 +0200
> Thorben Thuermer <r00t at constancy.org> wrote:
> > Hallo Eugen und andere,
> > 
> > Eugen hat mir inzwischen einen testzugang gegeben, und ich versuche das
> > weiter zu debuggen.
> > 
> > meine momentane vermutung ist, dass der bug nicht direkt in vzlogger ist,
> > sondern es ein problem mit libcurl (in verbindung mit einer mit fortify
> > kompilierten libc?) gibt.
> > (der crash passiert scheinbar immer aus libcurl heraus.)
> > https://wiki.ubuntu.com/Security/Features#Built_with_Fortify_Source
> > https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-D_FORTIFY_SOURCE.3D2
> > ein derartiges problem gab es wohl zB. hier schonmal:
> > https://bugzilla.redhat.com/show_bug.cgi?id=539809
> 
> libcurl mit debug kompiliert, man lese und staune...
> der crash passiert wohl reproduzierbar an der gleichen stelle in libcurl...
> hat also tatsaechlich was mit libcurl und dns zu tun,
> und wenn es an dns-timeouts liegt,
> wuerde das das zufaellige timing der crashes erklaeren.
> 
> [Oct 20 18:34:05][ch1]  CURL: Connection #0 to host localhost left intact
> [Oct 20 18:34:05][ch1]  Request succeeded: 200
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00007ffff6e52118 in addbyter (output=110, data=0x7ffff01b2580) at mprintf.c:1013
> 1013        infop->buffer[0] = outc; /* store */
> (gdb) bt full
> #0  0x00007ffff6e52118 in addbyter (output=110, data=0x7ffff01b2580) at mprintf.c:1013
>         infop = 0x7ffff01b2580
>         outc = 110 'n'
> #1  0x00007ffff6e50e4c in dprintf_formatf (data=0x7ffff01b2580, stream=0x7ffff6e520df <addbyter>,
>     format=0x7ffff6e808f3 "name lookup timed out", ap_save=0x7ffff01b25d0) at mprintf.c:671
> [...]
>         f = 0x7ffff6e808f3 "name lookup timed out"
> [...]
> #2  0x00007ffff6e52198 in curl_mvsnprintf (
>     buffer=0x404a30 "\377M\211l$\020A\211D$\b1\300ë¸ hostip.c:611
>           keep_sigact = {__sigaction_handler = {sa_handler = 0x7ffff01b27e0, sa_sigaction = 0x7ffff01b27e0}, sa_mask = {
> 
> 
> > - Thorben
> - T.
> 
> > On Fri, 21 Sep 2012 15:54:30 +0200 (CEST)
> > Eugen Sartoris <eugen at sartoris.de> wrote:
> > > Hallo Thorben,
> > > 
> > > danke für die Hinweise.
> > > Ich werde eine neue Testumgebung aufbauen unter ubuntu 10.04 und dann auch mit
> > > einem Deamon je Lesekopf ( insges. 3 )
> > > Wenn die Fehler isoliert sind melde ich mich wieder. Je nach Konfig der
> > > Testumgebung kann ich die einen Zugang einrichtern, sofern das für dich in Frage
> > > kommt.
> > > 
> > > gruss
> > > 
> > > eugen
> > > 
> > > 
> > > Thorben Thuermer <r00t at constancy.org> hat am 19. September 2012 um 22:45
> > > geschrieben:
> > > > On Wed, 19 Sep 2012 22:13:49 +0200 (CEST)
> > > > Eugen Sartoris <eugen at sartoris.de> wrote:
> > > > > ... ich werde noch weiter testen und die Infos dazu schicken.
> > > > > Vorab schon mal ein kleines TraceFile und das passende Log dazu.
> > > > kann da leider nichts sinnvolles drin erkennen...
> > > > (waehre auch vor allem zusammen mit dem dazugehoerigen backtrace hilfreich,
> > > > um zu sehen was der abgestuerzte thread zuletzt getan hat,
> > > > ich kann aus dem log nicht sehen, welcher thread den crash verursacht hat.)
> > > >
> > > > > Bisher habe ich alles auf Ubuntu 12.04 getestet.
> > > > > Damit ich ausschließen kann das es etwas mit der OS Version zu tun hat werde
> > > > > ich
> > > > > mir noch ein VM mit 10.04 installieren und die Test auch da noch machen...
> > > >
> > > > wenn du zeit zum herumprobieren hast, waehre es wohl vor allem sinnvoll zu
> > > > testen, ob der fehler mit einer anderen konstellation von zaehlern auch
> > > > auftritt,
> > > > zB wenn du fuer die vier zaehler vier einzelne vzlogger-instanzen
> > > > konfigurierst
> > > > und startest...
> > > >
> > > > alles in allem ist es schwer solche fehler zu debuggen, wenn man sie nicht
> > > > selbst
> > > > reproduzieren kann...
> > > >
> > > > > Gruss
> > > > > Eugen
> > > >
> > > > - Thorben