debuggen: Kennt sich jemand mit GDB aus?

Dr. Seltsam · 20. April 2008

Ich habe eine Ausgabe von GDB erhalten, die einen segmentation fault beim Beenden von vdr im pvrinput-Plugin dokumentiert. (siehe Anlage)

Aufgrund der angegebenen Funktionen hab ich eine ungefähre Idee, in welchem Bereich es klemmen muss. Ich wäre aber dankbar, falls ein Profi mir vielleicht helfen könnte, wie man da möglichst konkrete Details rauskriegt.

Das Problem tritt übrigens nur mit vdr 1.6.0, nicht aber mit 1.4.7 auf.

TheChief · 20. April 2008

Bin zwar kein GDB Profi und mit C hab ichs auch nicht so, aber bei Java sieht das ähnlich aus:

#0 0x52633631 in ?? ()
#1 0x080ef65f in cRingBufferLinear::Get ()
#2 0xb7a2f109 in cPvrDevice::GetTSPacket ()
from /usr/lib/vdr/plugins/libvdr-pvrinput.so.1.6.0
#3 0x0809e730 in cDevice::Action ()
#4 0x0810a76c in cThread::StartThread ()
#5 0xb7f47240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#6 0xb7d1f49e in clone () from /lib/tls/i686/cmov/libc.so.6

In dem Fall würd ich sagen Du solltest in der Funktion #1 cRingBufferLinear::Get () auf die suche gehen. Solltest Du da nichts finden, dann eventuell in cPvrDevice::GetTSPacket ().

Gruß
TheChief

Antiriad · 20. April 2008

Normalerweise spuckt der GDB auch den Highlevel Language Code aus, aber dafür müssen die Debuginformation vorhanden sein. Das scheint der Ausgabe nach aber nicht der Fall zu sein:
"Reading symbols from /usr/lib/vdr/plugins/libvdr-pvr350.so.1.6.0...(no debugging symbols found)...done."

Also am besten mal das Plugin und den VDR nach dem Bauen nicht mittels "strip" von den Debugsymbolen befreien.

gda · 20. April 2008

Zitat

Originally posted by Ioannis
Also am besten mal das Plugin und den VDR nach dem Bauen nicht mittels "strip" von den Debugsymbolen befreien.

und sicherstellen, dass der C++-Compiler die Option "-g" bekommt.

Gerald

Dr. Seltsam · 20. April 2008

Zitat

Original von gda

und sicherstellen, dass der C++-Compiler die Option "-g" bekommt.

Gerald

im Makefile steht

Code

### The C compiler and options:


CC       = gcc
CFLAGS   = -g -O2 -Wall


CXX      = g++
CXXFLAGS = -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses

sollte also reichen, oder?

Antiriad · 20. April 2008

Evtl. ist es zum Debuggen auch noch hilfreich die Optimierung abzuschalten, also -O0 statt -O2.

gda · 20. April 2008

Zitat

Originally posted by Ioannis
Evtl. ist es zum Debuggen auch noch hilfreich die Optimierung abzuschalten, also -O0 statt -O2.

Stimmt, sonst hüpft gdb bei Schleifen seltsam herum und hat immer genau
die Variable weg optimiert, die einen gerade interessiert.

Gerald

Dr. Seltsam · 21. April 2008

so, habe alles neu kompiliert und backtraces erstellt (siehe Anlage)

Leider werde ich mit meinen bescheidenen Kenntnissen nicht wirklich schlauer. Dies ausgewiesenen Stellen sind immer unterschiedlich, wobei immer wieder Action() beteiligt ist.

Die Zeile 244 in thread.c lautet:

void *cThread::StartThread(cThread *Thread)
{
Thread->childThreadId = ThreadId();
if (Thread->description)
dsyslog("%s thread started (pid=%d, tid=%d)", Thread->description, getpid(), Thread->childThreadId);
Thread->Action();
if (Thread->description)
dsyslog("%s thread ended (pid=%d, tid=%d)", Thread->description, getpid(), Thread->childThreadId);
Thread->running = false;
Thread->active = false;
return NULL;
}

Ich weiss bloß nicht, was in pvrinput`s Action() seit vdr 1.6.0 plötzlich falsch sein soll:

Code

void cPvrReadThread::Action(void) {
  unsigned char buffer[BUFFSIZE_INPUT];
  int r;
  active = true;
  log(3,"cPvrReadThread::Action(): Entering Action()"); 
  // A derived cThread class must check Running()
  // repeatedly to see whether it's time to stop.
  // see VDR/thread.h
  while (active && Running()) {
    r = read(video_fd, buffer, BUFFSIZE_INPUT); //Zeile 367
    if (r == -1) {
      log(0, "cPvrReadThread::Action():error reading from video device, %d:%s",
        errno, strerror(errno));
      break;
      }
    if (r > 0)  {
      ParseProgramStream(buffer, r);
      }
    }
  log(3,"cPvrReadThread::Action(): leaving Action()"); 
}

Alles anzeigen

Kompletter Plugin-Code:
http://drseltsam.device.name/v…g/pvrinput-2007-11-29.tgz

gda · 22. April 2008

Zitat

Originally posted by Dr. Seltsam
Leider werde ich mit meinen bescheidenen Kenntnissen nicht wirklich schlauer. Dies ausgewiesenen Stellen sind immer unterschiedlich, wobei immer wieder Action() beteiligt ist.
[/URL]

Das ist schwierig. Die Fehlermeldungen deuten daraufhin dass irgendwo
der Stack überschrieben wird. Action() selbst sieht aber sauber aus.
In ParseProgramStream() scheint auf den ersten Blick nicht sichergestellt
zu sein, dass pes_buffer nicht überläuft, aber pes_buffer liegt nicht auf dem
Stack. Ich würde mir trotzdem ParseProgramStream() genauer ansehen.
Wie ich schon sagte, das ist schwierig, da würde auch ich schon
ein bisschen länger dran sitzen und ich mach so was beruflich.

Gerald

gda · 22. April 2008

PesToTs() mit ts_buffer[] ist aber auch ein Kandidat.

Diese Zeile hat mich erst etwas irritiert:

Code

pos += Length - pos;

aber das ist einfach

Code

pos = Length;

Vielleicht ist ParseProgramStream() doch unschuldig, schau mal nach
PesToTs()

Gerald

gda · 22. April 2008

ts_buffer ist hardcoded auf 188 Bytes, aber es wird mit TS_SIZE bytes
an PutData übergeben. Steht TS_SIZE auf 188 Bytes?

Gerald

wirbel · 22. April 2008

Ein TS paket hat immer 188 bytes - ja.

Dr. Seltsam · 22. April 2008

was ich vielleicht noch erwähnen sollte:

immer dann, wenn vdr beim Beenden mit Strg-C hängt, habe ich in der Auflistung von top keinen vdr-Prozess mehr. Trotzdem muss noch einer da sein, denn erst ein "killall -9 vdr" führt dazu, dass das programm wirklich beendet wird.

Wenn da in ParseProgramStream() und/oder PesToTs() ein Bug ist, dann muss er sehr alt sein. Ich habe spaßeshalber mal diese beiden Funktionen aus der älteren 0.1.1-Version (die letzte, die der ursprüngliche Author noch selbst veröffentlicht hatte) reinimportiert. Ist genau das gleiche ...

gda · 22. April 2008

Zitat

Originally posted by Dr. Seltsam
Wenn da in ParseProgramStream() und/oder PesToTs() ein Bug ist, dann muss er sehr alt sein. Ich habe spaßeshalber mal diese beiden Funktionen aus der älteren 0.1.1-Version (die letzte, die der ursprüngliche Author noch selbst veröffentlicht hatte) reinimportiert. Ist genau das gleiche ...

Diese beiden Methoden rufen aber Funktionen des VDR auf, dann würde
ich da weiter nach Unverträglichkeiten suchen. Ich bleibe dabei, dass
das Fehlerbild durch einen kaputten Stack hervorgerufen wird. Mit
größter Wahrscheinlichkeit durch ein übergelaufenes Array.

Wenn alles nichts hilft, dann brauchst du Valgrind.

Gerald

Macavity · 22. April 2008

Hi,

ich schliesse mich mal gda an.

Anbei ist mal das Diff der ringbuffer.c von 1.4.7 und 1.6.0 (farblich auch als HTML). Da hat sich ein wenig geändert.

Ich würde einfach mal die ringbuffer.c vom 1.6.0 mit der vom 1.4.7 ersetzen und neu bauen.

Wenn der Fehler dann weg ist, hast Du deinen "Schuldigen".

Gruss

Macavity

P.S.: Bei der ringbufferDiff.htm.txt bitte das .txt entfernen.

gda · 22. April 2008

Da haben wir es doch schon in "uchar *cRingBufferLinear::Get(int &Count)":

Code

uchar *p = buffer + tail;
if ((cont = DataReady(p, cont)) > 0) {
     Count = gotten = cont;
     return p;
}

Das geht doch ganz furchtbar in die Hose.

Gerald

gda · 22. April 2008

Für einen schnellen Test ob es das ist, einfach mal

Code

static uchar *p = buffer + tail;

schreiben.

Gerald

gda · 22. April 2008

Nur bloss nicht so lassen! Das ist nicht reentrant!

Gerald

gda · 22. April 2008

Ist Quatsch was ich geschrieben habe, p ist zwar weg, aber der buffer
ist ja noch da.

Eine Woche Kernel-Treiber debuggen mach mürbe.

Gerald

Dr. Seltsam · 22. April 2008

ich setzte trotzdem alle meine Hoffnungen auf Dich

debuggen: Kennt sich jemand mit GDB aus?

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema