[vz-dev] Dockstar - vzlogger Core Dump

[Thorben Thuermer]

On Fri, 6 Jan 2012 19:32:16 +0100 (CET)
"Gerhard Bertelsmann" <info at gerhard-bertelsmann.de> wrote:
> Ich habe mal folgendes gemacht:
> root at Stromkasten:~# export LD_PRELOAD=libefence.so.0.0

ich wuerde tendentiell eher:
$ gdb vzlogger 
(gdb) efence
(gdb) run
weiss aber nicht ob das hier einen unterschied macht.

> root at Stromkasten:~# vzlogger -d
>   Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens.
> [Jan 06 19:06:07][mtr0] New meter initialized (protocol=sml)
> 
> Brach dann nach ein paar Messungen ab:
[...]
> [Jan 06 19:11:07][ch2]  Request succeeded with code: 200
ich kann da keinerlei fehlermeldugen erkennen...?

> GDB sagt:
> root at Stromkasten:~# gdb /usr/local/bin/vzlogger -c /core
> warning: exec file is newer than core file.
(das bedeutet normalerweise, dass du was falsch gemacht hast...
 ist aber hier wohl egal.)

> Program terminated with signal 11, Segmentation fault.
> (gdb) bt full
> #0  0x4024fa88 in pthread_cancel (th=1920233071) at pthread_cancel.c:35
>         pd = 0x72746e6f
> #1  0x0000ae94 in quit (sig=<optimized out>) at src/vzlogger.c:235
> #2  <signal handler called>
> #3  0x4024a0c8 in pthread_join (threadid=1091154976, thread_return=0x0) at
> pthread_join.c:89
>         _buffer = {__routine = 0x40249fb0 <cleanup>, __arg = 0x4109b63c,
> #4  0x0000aa34 in main () at src/vzlogger.c:418
> 
> Ich bin kein GDB Spezialist. Verursacht der Aufruf von pthread_cancel den
> Fehler ?

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)

ansonsten werden da wohl die von vzlogger verwendeten threads aufgeraeumt,
und bei einem davon tritt dann der fehler auf.

entweder ist der parameter den vzlogger an pthread_cancel uebergibt
ungueltig (weiss nicht genau wie pthreads sich da verhaelt,
bzw ob ein pthread_t jetzt ein pointer oder nur eine ID ist),
oder es ist wiederum eine interne datenstruktur von pthreads kaputt.

allgemein hatte ich nicht damit gerechnet, dass da threads verwendet werden,
es man gut sein, dass es sich um ein nebenlaeufigkeitsproblem handelt.

habe leider auch erstmal keine weiteren vorschlage,
ausser nochmal zu schauen ob der absturz immer auf die gleiche art passiert,
und den start direkt in gdb zu versuchen.
(der unterschied ist eigentlich nur, dass der umweg ueber das corefile
 wegfaellt, man kann immernoch per generate-core-file eins erzeugen.)

> Gruß
> Gerd

- T.