Merkwürdiger Crash im VDR

Thomas · 17. August 2006

Hallo,

ich finde schon seit geraumer Zeit "merkwürdige" coredumps im VDR-Verzeichnis.
Merkwürdig deshalb, weil ich mir keinen Reim drauf machen kann, was da passiert.

Folgender Code (tools.c):

Code

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

Der Backtrace dazu ist:

Code

#0  0x08100ba5 in cListBase::Clear (this=0x81e9044) at tools.c:1457
#1  0x08100887 in ~cListBase (this=0xb74704c8) at tools.c:1372
#2  0x080f301c in __tcf_0 () at status.c:14
#3  0xb7d67562 in exit () from /lib/libc.so.6
#4  0xb7d51568 in __libc_start_main () from /lib/libc.so.6
#5  0x080887a1 in _start ()
(gdb) print object
$2 = (cListObject *) 0x0
(gdb) print objects
$3 = (cListObject *) 0x9ed5a58

Ich verstehe nicht, was da crashen könnte?
Das while() müsste Nullpointer-Zugriffe doch abfangen?

slime · 17. August 2006

als jemand der net wirklich viel ahnung von der sache hat würde ich mal tippen, das da vllt. ein:

Code

while (objects->Next()) {
        cListObject *object = objects->Next();

stehen müsste.

ansonsten erhält man ja vllt. schon in der 2ten Zeile nen null-zeiger.
wobei das auch net so wirklich sein kann, weil mit dem 'object' wird dann ja nix gemacht, also eigentlich auch kein crash.

(vllt. sollte ich über pointer nicht referieren :P)

Urig · 18. August 2006

Weist du, mit welcher exception er ausgestiegen ist? wäre noch gut zu wissen.

Die Zeilenangabe (1457) ist vermutlich falsch geraten. Dieser build ist doch sicher code-optimiert übersetzt, oder?
Jedenfalls kann an dieser Code-Zeile objects nicht verschieden von NULL sein.

Wenn ich raten müsste, würde ich sagen, die Dereferenzierung objects->Next() führt ins nirgendwo. cList ist da nicht wirklich zuverlässig geschrieben, man kann leicht die Listenstruktur durcheinander bringen. Wenn dann ein eigentlich schon freigegebenes Listenobjekt überschrieben wurde, knallts.

Schwer zu sagen, wo da der Fehler ist, zumal noch nicht erkennbar ist, welche cList hier freigegeben wird. Wenn du es irgendwie provozieren kannst, versuch mal mit Valgrind dran zu gehen, da müsste dann die falsche Dereferenzierung erkannt werden.

Gruß,

Udo

Thomas · 18. August 2006

Zitat

Original von Urig
Dieser build ist doch sicher code-optimiert übersetzt, oder?

VDR standardmäßig mit "make" übersetzt.
Wie könnte ich denn die Optimierung aussetzen?

anbr · 18. August 2006

Zitat

Original von Thomas
VDR standardmäßig mit "make" übersetzt.
Wie könnte ich denn die Optimierung aussetzen?

Zum Bleistift mit einer eigenen Make.config, und darüber mit der Definition von CXXFLAGS auf -O0 ...
Die Datei in src Verzeichnis werfen, und den VDR normal mit make übersetzen.

Code

# Default for any build
CXXFLAGS = -fPIC -Wall -Woverloaded-virtual


# Add for optimierte Build
#CXXFLAGS += -march=i686 -msse -mmmx -mfpmath=sse -O3 -pipe -fomit-frame-pointer


# Add to enable Debugstuff
CXXFLAGS += -g -ggdb -O0
LDFLAGS += -g -ggdb -O0

Alles anzeigen

Ich hoffe ich erwähne hier Sachen, die nicht ehe schon bekannt sind,
Andreas

BlackKing · 18. August 2006

[Weit aus dem Fenster raushängen]

könnte man nicht einfach das ganze cListIrgendwas mit Containern aus der STL ersetzen?

Thomas · 18. August 2006

Zitat

Original von Hulk
Ich hoffe ich erwähne hier Sachen, die nicht ehe schon bekannt sind,

Mir noch nicht, vielen Dank
Werd's ausprobieren und dann berichten!

Urig · 19. August 2006

Zitat

Originally posted by BlackKing
könnte man nicht einfach das ganze cListIrgendwas mit Containern aus der STL ersetzen?

Sicher könnte man. Da aber cList quer durch VDR und die meisten Plugins verwendet wird, wirst du ohne eine Emulation von cList deinen VDR wohl kaum noch übersetzt kriegen. Aber da Klaus ein bekennender STL-Hasser ist, wird uns das wohl so schnell nicht bevor stehen.

(btw: mit 'nicht wirklich zuverlässig' meinte ich nicht, dass es fehlerhaft wäre. Man kann cList nur leicht falsch benutzen und so für herrliche Programmfehler sorgen. Und: Ja, ich spreche aus Erfahrung. )

Gruß,

Udo

UFO · 19. August 2006

Der Code der Clear-Routine ist an sich in Ordnung. Probleme treten dann auf, wenn mehrere Threads die gleiche Liste simultan "bearbeiten". Der Code ist mit Sicherheit nicht thread-safe.

Laut Backtrace sieht es so aus, als ob der Crash beim Stoppen des vdr auftritt (... exit() ...). Vielleicht werkelt da noch ein anderer Thread...

CU
Oliver

Thomas · 20. August 2006

So, hab das jetzt mal wie angegeben umcompiliert.

Code

#0  0x081383c6 in cListBase::Clear (this=0x822d4c4) at tools.c:1452
1452            delete objects;
(gdb) bt
#0  0x081383c6 in cListBase::Clear (this=0x822d4c4) at tools.c:1452
#1  0x08137fb7 in ~cListBase (this=0x822d4c4) at tools.c:1372
#2  0x08126f5d in ~cList (this=0x822d4c4) at status.c:14
#3  0x08126e52 in __tcf_0 () at status.c:14
#4  0xb7cb0562 in exit () from /lib/libc.so.6
#5  0xb7c9a568 in __libc_start_main () from /lib/libc.so.6
#6  0x08095d41 in _start ()
Current language:  auto; currently c++
(gdb) print objects
$1 = (cListObject *) 0xa177498
(gdb) print object
$2 = (cListObject *) 0x0

Alles anzeigen

Der Code komplett:

Code

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

objects ist nicht NULL, aber es knallt trotzdem?
Die Zeile stimmt doch immer noch nicht...

Der Segfault tritt übrigens tatsächlich beim Runterfahren auf, ich kann das beliebig provozieren.

ARK · 20. August 2006

Hmm, bei dem neuen Code steht doch:

Code

#0  0x081383c6 in cListBase::Clear (this=0x822d4c4) at tools.c:1452
1452            delete objects;
(gdb) bt
#0  0x081383c6 in cListBase::Clear (this=0x822d4c4) at tools.c:1452

d.h. der Fehler tritt beim delete auf. Also vermutlich doch ein delete auf ein bereits gelöschtes Objekt. Die Stelle bekommt man ohne Mutex eigentlich nicht threadsafe, aber mit einer gewissen Umkehrung der Reihenfolge wird die Wahrscheinlichkeit geringer. Was passiert denn bei:

Code

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

Gruß,
ARK

Thomas · 21. August 2006

Ich bau das in meinem VDR mal um und werd das Verhalten beobachten, ich berichte dann

Urig · 21. August 2006

Es wird wohl ein Verkettungsfehler in der Liste sein, wodurch ein ungültiger Zeiger an delete übergeben wird. So lange aber nicht mal klar ist, welche Liste hier freigegeben wird, ist der Fehler so nicht zu finden.

Ich kann nur nochmal empfehlen, da mal mit Valgrind nachzuforschen. Valgrind dürfte den Zeiger auch noch nach dem Freigeben wieder erkennen, und kann ihn zuordnen.

Gruß,

Udo

Thomas · 21. August 2006

Ich bin mir nicht so sicher ob ich mit valgrind effektiv umgehen kann.

Hier ist mal die Ausgabe davon, wenn ich den VDR beende:

Code

==7550==
==7550== Thread 1:
==7550== Mismatched free() / delete / delete []
==7550==    at 0x401C4D9: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==7550==    by 0x4DB7C76: cPluginRadio::~cPluginRadio() (radio.c:339)
==7550==    by 0x80F911B: cDll::~cDll() (plugin.c:157)
==7550==    by 0x8138201: cListBase::Del(cListObject*, bool) (tools.c:1415)
==7550==    by 0x80FA727: cPluginManager::Shutdown(bool) (plugin.c:470)
==7550==    by 0x813F316: main (vdr.c:1226)
==7550==  Address 0xCB2ADE0 is 0 bytes inside a block of size 23 alloc'd
==7550==    at 0x401B495: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==7550==    by 0x41EBD9F: strdup (in /lib/libc-2.3.5.so)
==7550==    by 0x4DB801E: cPluginRadio::Start() (radio.c:426)
==7550==    by 0x80FA020: cPluginManager::StartPlugins() (plugin.c:353)
==7550==    by 0x813BE68: main (vdr.c:614)
==7550==
==7550== Mismatched free() / delete / delete []
==7550==    at 0x401C4D9: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==7550==    by 0x4DB7C91: cPluginRadio::~cPluginRadio() (radio.c:340)
==7550==    by 0x80F911B: cDll::~cDll() (plugin.c:157)
==7550==    by 0x8138201: cListBase::Del(cListObject*, bool) (tools.c:1415)
==7550==    by 0x80FA727: cPluginManager::Shutdown(bool) (plugin.c:470)
==7550==    by 0x813F316: main (vdr.c:1226)
==7550==  Address 0xCB2AE70 is 0 bytes inside a block of size 23 alloc'd
==7550==    at 0x401B495: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==7550==    by 0x41EBD9F: strdup (in /lib/libc-2.3.5.so)
==7550==    by 0x4DB804A: cPluginRadio::Start() (radio.c:428)
==7550==    by 0x80FA020: cPluginManager::StartPlugins() (plugin.c:353)
==7550==    by 0x813BE68: main (vdr.c:614)
==7550==
==7550== Mismatched free() / delete / delete []
==7550==    at 0x401C4D9: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==7550==    by 0x4DB7CAC: cPluginRadio::~cPluginRadio() (radio.c:341)
==7550==    by 0x80F911B: cDll::~cDll() (plugin.c:157)
==7550==    by 0x8138201: cListBase::Del(cListObject*, bool) (tools.c:1415)
==7550==    by 0x80FA727: cPluginManager::Shutdown(bool) (plugin.c:470)
==7550==    by 0x813F316: main (vdr.c:1226)
==7550==  Address 0xCB2AEB8 is 0 bytes inside a block of size 33 alloc'd
==7550==    at 0x401B495: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==7550==    by 0x41DF31A: vasprintf (in /lib/libc-2.3.5.so)
==7550==    by 0x41C815C: asprintf (in /lib/libc-2.3.5.so)
==7550==    by 0x4DB8079: cPluginRadio::Start() (radio.c:430)
==7550==    by 0x80FA020: cPluginManager::StartPlugins() (plugin.c:353)
==7550==    by 0x813BE68: main (vdr.c:614)
==7550==
==7550== Mismatched free() / delete / delete []
==7550==    at 0x401C4D9: operator delete(void*) (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==7550==    by 0x4DB7CC7: cPluginRadio::~cPluginRadio() (radio.c:342)
==7550==    by 0x80F911B: cDll::~cDll() (plugin.c:157)
==7550==    by 0x8138201: cListBase::Del(cListObject*, bool) (tools.c:1415)
==7550==    by 0x80FA727: cPluginManager::Shutdown(bool) (plugin.c:470)
==7550==    by 0x813F316: main (vdr.c:1226)
==7550==  Address 0xCB2AF10 is 0 bytes inside a block of size 34 alloc'd
==7550==    at 0x401B495: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==7550==    by 0x41DF31A: vasprintf (in /lib/libc-2.3.5.so)
==7550==    by 0x41C815C: asprintf (in /lib/libc-2.3.5.so)
==7550==    by 0x4DB80A6: cPluginRadio::Start() (radio.c:432)
==7550==    by 0x80FA020: cPluginManager::StartPlugins() (plugin.c:353)
==7550==    by 0x813BE68: main (vdr.c:614)
==7550==
==7550== Conditional jump or move depends on uninitialised value(s)
==7550==    at 0x4D3C4A5: cFileInfo::Type() (helpers.c:203)
==7550==    by 0x4D3CC3A: cFileCMD::Del(char*) (helpers.c:374)
==7550==    by 0x4D3B761: cDVDPlugin::KillLink() (dvdplugin.h:29)
==7550==    by 0x4D3B6D5: cDVDPlugin::Finish() (dvdplugin.h:44)
==7550==    by 0x4D3AF99: cPluginDvdswitch::~cPluginDvdswitch() (dvdswitch.c:59)
==7550==    by 0x80F911B: cDll::~cDll() (plugin.c:157)
==7550==    by 0x8138201: cListBase::Del(cListObject*, bool) (tools.c:1415)
==7550==    by 0x80FA727: cPluginManager::Shutdown(bool) (plugin.c:470)
==7550==    by 0x813F316: main (vdr.c:1226)
==7550==
==7550== Conditional jump or move depends on uninitialised value(s)
==7550==    at 0x4D3C4AE: cFileInfo::Type() (helpers.c:203)
==7550==    by 0x4D3CC3A: cFileCMD::Del(char*) (helpers.c:374)
==7550==    by 0x4D3B761: cDVDPlugin::KillLink() (dvdplugin.h:29)
==7550==    by 0x4D3B6D5: cDVDPlugin::Finish() (dvdplugin.h:44)
==7550==    by 0x4D3AF99: cPluginDvdswitch::~cPluginDvdswitch() (dvdswitch.c:59)
==7550==    by 0x80F911B: cDll::~cDll() (plugin.c:157)
==7550==    by 0x8138201: cListBase::Del(cListObject*, bool) (tools.c:1415)
==7550==    by 0x80FA727: cPluginManager::Shutdown(bool) (plugin.c:470)
==7550==    by 0x813F316: main (vdr.c:1226)
==7550==
==7550== Conditional jump or move depends on uninitialised value(s)
==7550==    at 0x4D3C4B7: cFileInfo::Type() (helpers.c:203)
==7550==    by 0x4D3CC3A: cFileCMD::Del(char*) (helpers.c:374)
==7550==    by 0x4D3B761: cDVDPlugin::KillLink() (dvdplugin.h:29)
==7550==    by 0x4D3B6D5: cDVDPlugin::Finish() (dvdplugin.h:44)
==7550==    by 0x4D3AF99: cPluginDvdswitch::~cPluginDvdswitch() (dvdswitch.c:59)
==7550==    by 0x80F911B: cDll::~cDll() (plugin.c:157)
==7550==    by 0x8138201: cListBase::Del(cListObject*, bool) (tools.c:1415)
==7550==    by 0x80FA727: cPluginManager::Shutdown(bool) (plugin.c:470)
==7550==    by 0x813F316: main (vdr.c:1226)
==7576==
==7576== Thread 8:
==7576== Jump to the invalid address stated on the next line
==7576==    at 0x4BB009C: ???
==7576==    by 0x4BD7494: ???
==7576==    by 0x4BD75E3: ???
==7576==    by 0x4C0405E: ???
==7576==    by 0x4C03EEF: ???
==7576==    by 0x4BCAB90: ???
==7576==    by 0x4C05BC8: ???
==7576==    by 0x812F5A1: cThread::StartThread(cThread*) (thread.c:244)
==7576==    by 0x404B13C: pthread_start_thread (in /lib/libpthread-0.10.so)
==7576==    by 0x423B739: clone (in /lib/libc-2.3.5.so)
==7576==  Address 0x4BB009C is not stack'd, malloc'd or (recently) free'd
==7576==
==7576== Process terminating with default action of signal 11 (SIGSEGV)
==7576==  Access not within mapped region at address 0x4BB009C
==7576==    at 0x4BB009C: ???
==7576==    by 0x4BD7494: ???
==7576==    by 0x4BD75E3: ???
==7576==    by 0x4C0405E: ???
==7576==    by 0x4C03EEF: ???
==7576==    by 0x4BCAB90: ???
==7576==    by 0x4C05BC8: ???
==7576==    by 0x812F5A1: cThread::StartThread(cThread*) (thread.c:244)
==7576==    by 0x404B13C: pthread_start_thread (in /lib/libpthread-0.10.so)
==7576==    by 0x423B739: clone (in /lib/libc-2.3.5.so)
==7550==
==7550== ERROR SUMMARY: 1097 errors from 27 contexts (suppressed: 294 from 7)
==7550== malloc/free: in use at exit: 31,950,145 bytes in 599,180 blocks.
==7550== malloc/free: 888,259 allocs, 289,079 frees, 91,789,010 bytes allocated.
==7550== For counts of detected errors, rerun with: -v
==7550== searching for pointers to 599,180 not-freed blocks.
==7550== checked 47,345,664 bytes.
==7550==
==7550== LEAK SUMMARY:
==7550==    definitely lost: 258,593 bytes in 27 blocks.
==7550==      possibly lost: 163,828 bytes in 18 blocks.
==7550==    still reachable: 31,527,724 bytes in 599,135 blocks.
==7550==         suppressed: 0 bytes in 0 blocks.
==7550== Use --leak-check=full to see details of leaked memory.

Alles anzeigen

Kann ich irgendwie mehr oder andere Info entlocken, die weiter hilft?

Urig · 22. August 2006

Zunächst mal findet er reichlich verdächtige Stellen und kleinere Fehler im Radio-Plugin und im DVD-Plugin. Das sieht mir aber alles eher nach übersehenen, aber unkritischen Fehlern aus.

Dann kommt aber der "Thread 8" - für den es anscheinend keine Symbolinfos gibt. Warum, weiß ich auch nicht. Jedenfalls produziert dieser Thread einen segfault irgendwo tief drin.

Um etwas mehr Übersicht zu gewinnen, solltest du so wenig Plugins wie möglich laden - natürlich nur, so lange das Problem bestehen bleibt. Und schau mal, ob du rausfinden kannst, was Thread 8 ist.

Gruß,

Udo

Merkwürdiger Crash im VDR

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema