[vz-dev] Dockstar - vzlogger Core Dump

[Gerhard Bertelsmann]

Hallo,

Am So, 8.01.2012, 08:31, schrieb Thorben Thuermer:
> On Sun, 8 Jan 2012 00:42:57 +0100 (CET)
> "Gerhard Bertelsmann" <info at gerhard-bertelsmann.de> wrote:
> [...]
>> > was ich hier nicht verstehe ist, dass der absturz in einem teil des
>> codes
>> > passiert, der beim _beenden_ von vzlogger ablaeuft, ohne dass
>> erkennbar
>> > ist
>> > warum das programm beendet wird, was vermutlich interessanter waehre
>> zu
>> > wissen, als warum es dabei dann abstuerzt.
>> > (in main () at src/vzlogger.c:418)
>>
>> Ich habe hier leider ein wenig dazwischen experimentiert. Der o.g. Core
>> Dump
>> stammt von vzlogger (ohne -d).
>
> kannst du denn nachvollziehen, ob der segfault immer an der gleichen
> stelle
> passiert? die beiden backtraces bisher waren ja arg verschieden, oder lag
> das an efence, und ist mit bzw ohne efence konsistent?

Ich habe eher das Gefühl, das Efence in die Irre führt. Zudem läuft es
anscheinend
nicht sauber auf Armel mit nur 128MB Speicher ...
Valgrind steigt übrigens sofort auf Dockstar aus.
>
>> Bei mir bricht vzlogger -f nach einer Messung ab.
>> Ist das bei Euch auch so ?
>
> wir sollten das ganze verschieben bis steffen da ist, der kann sowas
> schneller beantworten.

OK. Warten wir bis der Meister kommt :-)
>
>> Da efence auf der Dockstar für mich keinen brauchbaren Output liefert
>> (insbesondere mit dem Daemon)
> fuer solche tests sollte man allgemein immer den no-daemon modus des
> jeweiligen programms benutzen.
>
>> habe ich vzlogger auf einer Ubuntu Oneric AMD64 Maschine
>> verlagert.
> [...]
>> Ich habe mal versuchsweise vlagrind benutzt:
>> valgrind --leak-check=yes --trace-children=yes
>> --log-file=vz_valgrind.log
>> /usr/local/bin/vzlogger -d
>>
>> Dabei kommt folgendes raus:
>
>> ==29358== Thread 1:
>> ==29358== 19 bytes in 1 blocks are definitely lost in loss record 11 of
>> 603
>> ==29358==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
>> ==29358==    by 0x5BCC441: strdup (strdup.c:43)
>> ==29358==    by 0x407E0D: meter_open_sml (sml.c:114)
>
> ich vermute mal das libsml dann memory-leaks hat, das scheint plausibel,
> ist ja eine relativ neue entwicklung...
> dieser ist nicht so relevant, da nur bei der initialisieren, aber...
>
>> ==29358== 354 (192 direct, 162 indirect) bytes in 3 blocks are
>> definitely
>> lost in loss record 548 of 603
>> ==29358==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
>> ==29358==    by 0x50401FD: sml_list_init (in /usr/lib/libsml.so.1.1)
>> ==29358==    by 0x504024E: sml_list_entry_parse (in
>> /usr/lib/libsml.so.1.1)
>> ==29358==    by 0x50403E4: sml_list_parse (in /usr/lib/libsml.so.1.1)
>> ==29358==    by 0x5042585: sml_get_list_response_parse (in
>> /usr/lib/libsml.so.1.1)
>> ==29358==    by 0x503FADF: sml_message_body_parse (in
>> /usr/lib/libsml.so.1.1)
>> ==29358==    by 0x503FD59: sml_message_parse (in /usr/lib/libsml.so.1.1)
>> ==29358==    by 0x503E3DF: sml_file_parse (in /usr/lib/libsml.so.1.1)
>> ==29358==    by 0x4079FF: meter_read_sml (sml.c:151)
>
> wenn libsml beim parsen von nachrichten ein leck hat, wuerde das den
> speicherverbrauch erklaeren...
> https://github.com/dailab/libsml/blob/dd813cd5b5a142240f93ab5e24759806ab2e05ec/sml/src/sml_list.c#L109
> sml_list_entry_parse() erzeugt zB. bei jedem aufruf eine sml_list,
> und wenn dann beim parsen ein problem auftritt, wird diese nicht wieder
> freigegeben, ist die frage wie oft das auftritt...
> da muesste fuer fehler die nach sml_list_init auftreten noch
> die liste wieder freigeben werden. (simple aenderung.)
> (der kommentar, dass der speicher in sml_list_parse freigegen wird ist
>  nicht sinnvoll, da es sich um eine lokale variable handelt,
>  die im fehlerfall den aufrufer nicht erreicht.)
>
> wie lange lief vzlogger da? denn viel ist es ja hier (noch?) nicht.
>
>> GDB sagt:
>> root at spartanew ~ # gdb /usr/local/bin/vzlogger -c
>> vz_valgrind.log.core.29358
>> [Thread debugging using libthread_db enabled]
>> Cannot find new threads: generic error
>> (gdb) bt full
>> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
>> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
>> No locals.
>> #1  0x00000000004053eb in logging_thread (arg=0x90bd450) at
>> src/threads.c:161
>
> das ist jetzt schon wieder eine andere stelle an der ein problem
> auftritt...?
> ich kann mir aber vorstellen, das das an valgrind liegt - wuerde versuchen
> das
> getrennt zu halten...

Anbei ein Link mit der valgrind Option, der den Child Prozeß beinhaltet:

http://lnxpps.de/vz_valgrind.log

Ehrlich gesagt: Ich kann damit nix anfangen ...

Wie ist es bei Euch: Hat jemand vzlogger auf einer nicht x86 Plattform
(z.B. Arm/AMD64) stabil am Laufen ? Endet bei Euch vzlogger
(im Vordergrund) auch nach einer Messung ? Dann sollte das Debugging
einfacher sein ...

Gruß

Gerd