C++ Debugging: Besitzer eines Objektes ermitteln?

Keine_Ahnung · 17. Januar 2012

Hallo,
mein VDR knallt beim beenden gerne mal in "tools.c"

Code

void cListBase::Clear(void)
{
  while (objects) {
        cListObject *object = objects->Next();
        delete objects;
        objects = object;
        }
  objects = lastObject = NULL;
  count = 0;
}

Kommentiere ich "delete objects" (das ist die Stelle die laut Backtrace das Problem hat) aus dann läuft alles super. Nun frage ich mich obs ne einfache Möglichkeit gibt zu erfahren welem Plugin das Object gehört welches Probleme bereitet. Gibts da irgendwas um das in Erfahrung zu bringen und ne Debugausgabe zu erstellen?

Den VDR im Debugger laufen zu lassen ist ja vermutlich keine Alternative weil er dann sowas von garnicht mehr läuft.

Code

Core was generated by `/usr/bin/vdr --device=1 --log=3 0 --port=6419 --user=vdr --userdump --vfat --wa'.
Program terminated with signal 11, Segmentation fault.
#0  0x0812e182 in cListBase::Clear (this=0x81a1e60) at tools.c:1831
1831	        delete objects;
#0  0x0812e182 in cListBase::Clear (this=0x81a1e60) at tools.c:1831
#1  0xb75142bf in __run_exit_handlers (status=0, listp=0xb7627304, 
    run_list_atexit=true) at exit.c:78
#2  0xb751432f in *__GI_exit (status=0) at exit.c:100
#3  0xb74fbc7e in __libc_start_main (main=0x81333d0 <main>, argc=63, 
    ubp_av=0xbfa4e714, init=0x814e980 <__libc_csu_init>, 
    fini=0x814e970 <__libc_csu_fini>, rtld_fini=0xb7879040 <_dl_fini>, 
    stack_end=0xbfa4e70c) at libc-start.c:260
#4  0x0809aae1 in _start ()
Current language:  auto
The current source language is "auto; currently c++".

Alles anzeigen

cu

mini73 · 17. Januar 2012

Moin!

Wenn das "delete objects" ein Problem mit dem Pointer hat, dann hat ihn wahrscheinlich ja ein anderer Programmteil schon freigegeben, obwohl er es nicht sollte.
Der Backtrace sieht ja nicht wirklich aussagekräftig aus...

Ich weiß nicht, ob es mit gdb möglich ist, nach der Adresse der Liste selbst zu suchen, dann hätte man ja schon mal einen Ansatzpunkt.

Ich selbst hab zwar noch nie mit Valgrind gearbeitet, aber das scheint das passende Werkzeug für so einen Fehler zu sein.

Lars.

Keine_Ahnung · 18. Januar 2012

Zitat von mini73

Wenn das "delete objects" ein Problem mit dem Pointer hat, dann hat ihn wahrscheinlich ja ein anderer Programmteil schon freigegeben, obwohl er es nicht sollte.

Wobei das laut delete Doku eigentlich kein Problem sein sollte. Jedenfalls lese ich das so das delete mit Nullpointern keine Probleme haben soll.
Meine beste Idee ist das der Pointer vorhanden (! NULL) aber nicht mehr auf ein Objekt zeigt. Wobei die Objekte an der Stelle eh nicht mehr exisiteren sollten, weil hier sind die Plugins ja eigentlich schon entladen.

Ich hatte gehofft das es da in C++ irgendwas gibt womit ein Objekt abfragen kann von welchen Objekt es erzeugt wurde. Dann wäre es einfach da etwas mehr Logging einzubauen.

Zitat von mini73

Ich weiß nicht, ob es mit gdb möglich ist, nach der Adresse der Liste selbst zu suchen, dann hätte man ja schon mal einen Ansatzpunkt.

Ich selbst hab zwar noch nie mit Valgrind gearbeitet, aber das scheint das passende Werkzeug für so einen Fehler zu sein.

Das Problem ist das es nicht immer ist, hängt vermutlich auch einwenig vom Zeitpunkt ab an dem der VDR beendet wird. Deswegen wäre es schön wenn man da was ins Syslog bekommt um die Infos mal zu sammeln (so im normalen Alltagbetrieb) und die problematischen Plugins eingrenzen zu können..

Ich glaube da kommt man nicht so einfach ran. Und eigentlich ist es an der Stelle ja auch egal, danach räumt Linux eh die Reste weg. Ich glaube ich stelle einfach mein Init Script so um das es keinen Absturz Loggt wenn die letzte Logzeile "exiting, exit code [0|1|2]" enthält. Dann stören die nicht weiter und ich bekomme nur die relevanten Abstürze zu sehen.

cu

mini73 · 18. Januar 2012

Moin!

Zitat von Keine_Ahnung

Wobei das laut delete Doku eigentlich kein Problem sein sollte. Jedenfalls lese ich das so das delete mit Nullpointern keine Probleme haben soll.

Der Pointer ist nicht NULL, wie du schon vermutest, denn an die Liste wird eine Kopie des Pointers gegeben. Und wenn ein anderer Programmpunkt den Speicher freigibt, auf den dieser Pointer zeigt, dann weiß der andere Teil davon nichts.

Code

int* eins = new int;
(*eins) = 1;
int* zwei = eins;
delete eins;

Der Pointer "zwei" zeigt immer noch auf den Speicher, der durch new reserviert wurde. "delete eins" verändert weder den Inhalt von "eins" noch von "zwei". Also auch, wenn du noch mal "delete eins" aufrufen würdest, würde der Fehler kommen.

Zitat von Keine_Ahnung

Ich glaube da kommt man nicht so einfach ran. Und eigentlich ist es an der Stelle ja auch egal, danach räumt Linux eh die Reste weg. Ich glaube ich stelle einfach mein Init Script so um das es keinen Absturz Loggt wenn die letzte Logzeile "exiting, exit code [0|1|2]" enthält. Dann stören die nicht weiter und ich bekomme nur die relevanten Abstürze zu sehen.

Dann wird aber evtl. ein Wakeup-Event o.ä. nicht gesetzt. Muss nicht sein, kann aber.

Zitat von Keine_Ahnung

und die problematischen Plugins eingrenzen zu können..

Immer eins nicht laden und ein paar mal testen...
Nicht zuverlässig reproduzierbare Fehler sind aber immer doof zu finden. Das Suchen bringt dann nicht viel Spaß.

Der vdr ist ja der Hauptprozess, der die Plugins als "shared objects" mittels dlopen nachlädt. Ich dachte, dass sie sich damit den gleichen Heap teilen, d.h. wenn ein Plugin ein Objekt mit new erzeugt und danach das Plugin entladen wird, dann sollte das Objekt noch existieren.
Jetzt wo ich das schreibe, wird es klar: Das delete versucht dann den Destruktor aufzurufen, aber der ist dann ja nicht mehr da! (oder denke ich falsch?)
Sollten die Plugins beim Beenden des vdr also nicht entladen werden? Wird beim Beenden eines Prozesses eventuell automatisch ein "dlclose" aufgerufen?

Lars.

C++ Debugging: Besitzer eines Objektes ermitteln?

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema