[vz-users] Auswertung Protocol d0 / deamon Absturz

Thorben Thuermer r00t at constancy.org
Mon Oct 22 13:40:44 CEST 2012 

On Mon, 22 Oct 2012 11:05:05 +0200
Eugen Sartoris  <eugen at sartoris.de> wrote:
> Hallo Thorben,
> 
> da hast du dir sehr viel Arbeit gemacht. Super Analyse. Vielen Dank.
>  
> Für die Testumgebung kann ich dir  auch noch den 2. ( d0 )
> und 3. (sml)  Lesekopf in die VM schalten.
> Dann wäre der Test mit 3 metern und 4 Channels möglich. 

also, fuer mich ist die sache im prinzip damit erledigt, die ursache
fuer die staendigen abstuerze gefunden und beseitigt zu haben,
und ich wuerde das dann eigentlich an dich zurueckgeben.

das einzige was noch gut waehre, waehre den crash im d0 parser nochmal
unter efence zu reproduzieren, um dort noch die ursache zu finden,
aber der tritt wohl sehr selten auf, und du solltest das auch selber
hinbekommen.

der aktuelle aufruf in der testumgebung (in einer screen session) ist:
LD_LIBRARY_PATH=/vz/libcurl-7.28.0-prefix/lib/ gdb
--args /vz/vzlogger.stv0g/src/vzlogger -f -c /etc/vzlogger-l_0.conf
(gdb) efence
(gdb) run
(um vzlogger zu beenden, entweder "killall vzlogger" und einmal "c"
in gdb, oder einfach in gdb ctrl-c und dann quit, und die warnung
das das programm gekillt wird bestaetigen.

du kannst dann ja mal wieder die "grosse" config einbauen.

> Bei meiner Urspünglichen Konfig ( 1 Deamon, 3 meter, 4 Channels) waren die Abstürze am häufigsten.
> Nach deinem Hinweis pro meter einen Daemon zu nutzten lief das System viel stabiler, insbesondere für meter1 u meter2.
> Bei meter0 sank die Häufigkeit der Abstürze.

das liegt nahe - je mehr middleware requests, desto eher wird die
race-condition zum crash fuehren, und bei dem d0-meter mit zwei
kanaelen ist sie wie gesagt besonders hoch.

> Gruss
> ES

- T.

> -----Ursprüngliche Nachricht-----
> Von:Thorben Thuermer <r00t at constancy.org>
> Gesendet:So 21.10.2012 17:30
> Betreff:Re: [vz-users] Auswertung Protocol d0 / deamon Absturz
> An:volkszaehler-users at lists.volkszaehler.org; 
> 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
>

More information about the volkszaehler-users mailing list