<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html>
<head>
<meta name="Generator" content="Zarafa WebAccess v7.1.0-36420">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>AW: [vz-users] Auswertung Protocol d0 / deamon Absturz</title>
<style type="text/css">
body
{
font-family: Arial, Verdana, Sans-Serif ! important;
font-size: 12px;
padding: 5px 5px 5px 5px;
margin: 0px;
border-style: none;
background-color: #ffffff;
}
p, ul, li
{
margin-top: 0px;
margin-bottom: 0px;
}
</style>
</head>
<body>
<p>Hallo Thorben,</p><p> </p><p>da hast du dir sehr viel Arbeit gemacht. Super Analyse. Vielen Dank.</p><p> </p><p> </p><p>Für die Testumgebung kann ich dir auch noch den 2. ( d0 ) und 3. (sml) Lesekopf in die VM schalten.</p><p>Dann wäre der Test mit 3 metern und 4 Channels möglich. </p><p> </p><p>Bei meiner Urspünglichen Konfig ( 1 Deamon, 3 meter, 4 Channels) waren die Abstürze am häufigsten.</p><p>Nach deinem Hinweis pro meter einen Daemon zu nutzten lief das System viel stabiler, insbesondere für meter1 u meter2.</p><p>Bei meter0 sank die Häufigkeit der Abstürze.</p><p> </p><p>Gruss</p><p> </p><p>ES<br /> </p><blockquote style="border-left: 2px solid #325FBA; padding-left: 5px;margin-left:5px;">-----Ursprüngliche Nachricht-----<br /><strong>Von:</strong> Thorben Thuermer <r00t@constancy.org><br /><strong>Gesendet:</strong> So 21.10.2012 17:30<br /><strong>Betreff:</strong> Re: [vz-users] Auswertung Protocol d0 / deamon Absturz<br /><strong>An:</strong> volkszaehler-users@lists.volkszaehler.org; <br />Hallo,<br /><br />das problem ist dann geklaert:<br />der resolver in libcurl ist _nicht_ thread-safe.<br /><br />d.h., wenn zwei threads gleichzeitig einen namen aufloesen, gibt es eine<br />race-condition die zu dem crash fuehrt.<br /><br />das ist recht eindeutig ein bug in libcurl...<br />unter: http://curl.haxx.se/libcurl/features.html<br />wird angegeben, libcurl sei dann thread-safe, wenn die gethostbyname()<br />funktion des betriebssystems thead-safe ist,<br />aber das problem liegt nicht in gethostbyname(), sondern in der benutzung<br />von alarm() um einen timeout fuer gethostbyname() zu erzwingen.<br />(related: https://bugzilla.redhat.com/show_bug.cgi?id=539809 ) <br /><br />in Eugen's konfiguration tritt das problem vor allem deshalb auf,<br />weil aus einem meter zwei channels erzeugt werden,<br />d.h. jedesmal wenn vom meter daten kommen, werden gleichzeitig zwei<br />middleware-aufrufe gestartet, um die daten der beiden channels zu<br />uebermitteln, was dann irgendwann das richtige timing fuer die race-condition<br />liefert und zum crash fuehrt.<br /><br />der crash tritt seltener auf, wenn man statt "localhost" direkt "127.0.0.1"<br />fuer den middleware-server angibt, vermutlich weil die aufloesung dann<br />schneller geht.<br />(ein externer dns-server ist in beiden faellen nicht involviert,<br /> da der name im hostsfile steht.)<br /><br />als fix waehre entweder der bug in libcurl zu beheben...<br />oder libcurl mit unterstuetzung fuer einen alternativen resolver zu kompilieren:<br />http://curl.haxx.se/dev/readme-ares.html<br /><br />ansonsten kann man als workaround libcurl ohne HAVE_ALARM kompilieren<br />(nach dem ./configure den HAVE_ALARM eintrag in lib/curl_config.h<br />entfernen oder auskommentieren (nicht 1 durch 0 ersetzen!).<br />(das hat den nachteil, dass das programm u.U. bei der aufloesung<br /> haengenbleibt, falls der timeout-mechanismus des betriebssystems<br /> nicht greift.)<br /><br />(Eugen: letzteres ist momentan bei dir in /vz/libcurl-7.28.0-prefix bzw<br /> /vz/curl-7.28.0 implementiert, vzlogger laeuft jetzt seit ueber<br /> zehn stunden durch.)<br /><br />- T.<br /><br />On Sat, 20 Oct 2012 22:41:27 +0200 Thorben Thuermer <r00t@constancy.org> wrote:<br />> On Sat, 20 Oct 2012 17:32:26 +0200<br />> Thorben Thuermer <r00t@constancy.org> wrote:<br />> > Hallo Eugen und andere,<br />> > <br />> > Eugen hat mir inzwischen einen testzugang gegeben, und ich versuche das<br />> > weiter zu debuggen.<br />> > <br />> > meine momentane vermutung ist, dass der bug nicht direkt in vzlogger ist,<br />> > sondern es ein problem mit libcurl (in verbindung mit einer mit fortify<br />> > kompilierten libc?) gibt.<br />> > (der crash passiert scheinbar immer aus libcurl heraus.)<br />> > https://wiki.ubuntu.com/Security/Features#Built_with_Fortify_Source<br />> > https://wiki.ubuntu.com/ToolChain/CompilerFlags#A-D_FORTIFY_SOURCE.3D2<br />> > ein derartiges problem gab es wohl zB. hier schonmal:<br />> > https://bugzilla.redhat.com/show_bug.cgi?id=539809<br />> <br />> libcurl mit debug kompiliert, man lese und staune...<br />> der crash passiert wohl reproduzierbar an der gleichen stelle in libcurl...<br />> hat also tatsaechlich was mit libcurl und dns zu tun,<br />> und wenn es an dns-timeouts liegt,<br />> wuerde das das zufaellige timing der crashes erklaeren.<br />> <br />> [Oct 20 18:34:05][ch1] CURL: Connection #0 to host localhost left intact<br />> [Oct 20 18:34:05][ch1] Request succeeded: 200<br />> <br />> Program received signal SIGSEGV, Segmentation fault.<br />> 0x00007ffff6e52118 in addbyter (output=110, data=0x7ffff01b2580) at mprintf.c:1013<br />> 1013 infop->buffer[0] = outc; /* store */<br />> (gdb) bt full<br />> #0 0x00007ffff6e52118 in addbyter (output=110, data=0x7ffff01b2580) at mprintf.c:1013<br />> infop = 0x7ffff01b2580<br />> outc = 110 'n'<br />> #1 0x00007ffff6e50e4c in dprintf_formatf (data=0x7ffff01b2580, stream=0x7ffff6e520df <addbyter>,<br />> format=0x7ffff6e808f3 "name lookup timed out", ap_save=0x7ffff01b25d0) at mprintf.c:671<br />> [...]<br />> f = 0x7ffff6e808f3 "name lookup timed out"<br />> [...]<br />> #2 0x00007ffff6e52198 in curl_mvsnprintf (<br />> buffer=0x404a30 "\377M\211l$\020A\211D$\b1\300ë¸ hostip.c:611<br />> keep_sigact = {__sigaction_handler = {sa_handler = 0x7ffff01b27e0, sa_sigaction = 0x7ffff01b27e0}, sa_mask = {<br />> <br />> <br />> > - Thorben<br />> - T.<br />> <br />> > On Fri, 21 Sep 2012 15:54:30 +0200 (CEST)<br />> > Eugen Sartoris <eugen@sartoris.de> wrote:<br />> > > Hallo Thorben,<br />> > > <br />> > > danke für die Hinweise.<br />> > > Ich werde eine neue Testumgebung aufbauen unter ubuntu 10.04 und dann auch mit<br />> > > einem Deamon je Lesekopf ( insges. 3 )<br />> > > Wenn die Fehler isoliert sind melde ich mich wieder. Je nach Konfig der<br />> > > Testumgebung kann ich die einen Zugang einrichtern, sofern das für dich in Frage<br />> > > kommt.<br />> > > <br />> > > gruss<br />> > > <br />> > > eugen<br />> > > <br />> > > <br />> > > Thorben Thuermer <r00t@constancy.org> hat am 19. September 2012 um 22:45<br />> > > geschrieben:<br />> > > > On Wed, 19 Sep 2012 22:13:49 +0200 (CEST)<br />> > > > Eugen Sartoris <eugen@sartoris.de> wrote:<br />> > > > > ... ich werde noch weiter testen und die Infos dazu schicken.<br />> > > > > Vorab schon mal ein kleines TraceFile und das passende Log dazu.<br />> > > > kann da leider nichts sinnvolles drin erkennen...<br />> > > > (waehre auch vor allem zusammen mit dem dazugehoerigen backtrace hilfreich,<br />> > > > um zu sehen was der abgestuerzte thread zuletzt getan hat,<br />> > > > ich kann aus dem log nicht sehen, welcher thread den crash verursacht hat.)<br />> > > ><br />> > > > > Bisher habe ich alles auf Ubuntu 12.04 getestet.<br />> > > > > Damit ich ausschließen kann das es etwas mit der OS Version zu tun hat werde<br />> > > > > ich<br />> > > > > mir noch ein VM mit 10.04 installieren und die Test auch da noch machen...<br />> > > ><br />> > > > wenn du zeit zum herumprobieren hast, waehre es wohl vor allem sinnvoll zu<br />> > > > testen, ob der fehler mit einer anderen konstellation von zaehlern auch<br />> > > > auftritt,<br />> > > > zB wenn du fuer die vier zaehler vier einzelne vzlogger-instanzen<br />> > > > konfigurierst<br />> > > > und startest...<br />> > > ><br />> > > > alles in allem ist es schwer solche fehler zu debuggen, wenn man sie nicht<br />> > > > selbst<br />> > > > reproduzieren kann...<br />> > > ><br />> > > > > Gruss<br />> > > > > Eugen<br />> > > ><br />> > > > - Thorben<br /></blockquote>
</body>
</html>