[vz-dev] Dockstar - vzlogger Core Dump

[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?

> 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.

> 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...

- T.