debuggen: Kennt sich jemand mit GDB aus?

Macavity · 22. April 2008

Hi,

ich geh jetzt auch erstmal schlafen. Morgen zieh ich mir mal den Source vom Plugin rein.

Gruss

Macavity

Dr. Seltsam · 23. April 2008

was mir noch auffiel:
Ist die Funktion PutData in der Klasse cPvrReadThread richtig angesiedelt? Beim pvrusb2-Plugin (dort heißt sie PutTSData) gehört sie zur Klasse
des devices. Dort wird die Funktion auch zusätzlich abgebrochen, wenn der tsBuffer nicht mehr existiert

wirbel · 23. April 2008

Niemand anders als der Thread selbst gibt Daten in tsBuffer. Ich seh keinen Grund, warum das woanders hingehören sollte.

Das mit dem Prüfen ob der Buffer existiert macht Sinn - aber nur wenn der Buffer vor dem Thread gelöscht werden kann.

Dr. Seltsam · 27. April 2008

so, wieder das ganze Wochenende gesucht und nichts gefunden
Meine Aussage, dass pvrinput mit vdr-1.5.11 noch einwandfrei läuft, ziehe ich zurück. Nach intensiven Tests musste ich auch dort feststellen, dass es beim Beenden sporadisch hängt.

Mit vdr 1.4.7 ist hingegen alles o.k.

gda · 27. April 2008

Da hilft wohl nur die Version 1.4.7 langsam auf die Version 1.5.11 hoch patchen bis
der Fehler auftritt und den Quelltext der letzten Änderung würde ich dann gerne sehen.

Gerald

Dr. Seltsam · 27. April 2008

ich bin mir inzwischen zu 99% sicher, dass der Ärger beim Wechsel von vdr 1.5.0 zu 1.5.1 anfing. Bisher habe ich es nicht geschafft, 1.5.0 beim Beenden aufzuhängen. Bei 1.5.1 geht das recht fix.

In der 1.5.1 ist der shutdown-rewrite-Patch eingelossen:
[ANNOUNCE] VDR developer version 1.5.1
sollte der etwa schuld sein?

gda · 28. April 2008

Mir fällt nicht wirklich was auf, aber kannst Du mal ein

Code

#include "shutdown.h"

am Anfang von device.c des Plugins so unter die Zeile

Code

#include "setup.h"

setzen und bei der Methode cPvrReadThread::Action(void) die Zeile

Code

while (active && Running()) {

ersetzen durch

Code

while (active && !ShutdownHandler.DoExit()) {

?

Gerald

Dr. Seltsam · 28. April 2008

Zitat
Original von gda
Mir fällt nicht wirklich was auf, aber kannst Du mal ein
Code
#include "shutdown.h"
am Anfang von device.c des Plugins so unter die Zeile
Code
#include "setup.h"
setzen

hab da mal ein #include <vdr/shutdown.h> draus gemacht

Zitat
und bei der Methode cPvrReadThread::Action(void) die Zeile
Code
while (active && Running()) {
ersetzen durch
Code
while (active && !ShutdownHandler.DoExit()) {
?

hängt leider gleich beim 2. Versuch

gda · 28. April 2008

Zitat

Original von Dr. Seltsam
hab da mal ein #include <vdr/shutdown.h> draus gemacht

Dumm von mir, das Plugin sitzt ja nicht im selben Verzeichnis wie der
vdr.

Zitat

Original von Dr. Seltsam
hängt leider gleich beim 2. Versuch

War auch blinder Aktionismus.

Gerald

Dr. Seltsam · 1. Mai 2008

so, ich habe die letzten Tage alle Versionen des shutdown-rewrite-Patches durchgetestet und konnte eingrenzen, dass das Problem mit den Änderungen aus anhängendem Patch auftritt. Udo Richter gab mir dann den Tip, in vdr.c mal einen isyslog auszukommentieren ("Eigentlich sollte isyslog threadsafe sein, aber bei Signalhandlern weiß man ja nie...") :

Code

static void SignalHandler(int signum)
{
//  isyslog("caught signal %d", signum);
  switch (signum) {
    case SIGPIPE:
         break;
    case SIGHUP:
         LastSignal = signum;
         break;
    default:
         LastSignal = signum;
         Interface->Interrupt();
         ShutdownHandler.Exit(0);
    }
  signal(signum, SignalHandler);
}

Alles anzeigen

Seitdem klappte das Beenden bislang ohne Probleme. Wäre nett, wenn das noch ein paar mehr vdr-1.6/pvrinput-User austesten könnten.

BerndV · 7. Mai 2008

Hallo zusammen,

Zitat

("Eigentlich sollte isyslog threadsafe sein, aber bei Signalhandlern weiß man ja nie...") :

ich habe (noch) keinen VDR laufen aber interessehalber mal die Quellen angeschaut.

isyslog() wird in tools.h als syslog_with_tid() #define'd.
syslog_with_tid() benutzt snprintf().

Wenn ich mich richtig erinnere (von früher...) dann darf man in Signal Handlern keinen Speicher dynamisch allokieren (malloc()) weil das schief gehen kann, der Signal Handler kann von irgendwo her aufgerufen werden, z.B. auch aus *printf() oder ähnlich. Ich nehme mal an dass snprintf() typischerweise auch dynamisch Speicher allokiert. Damit hat das Ganze dann Potential zu crashen.

Nur so als Vermutung...

Viele Grüße,
Bernd

debuggen: Kennt sich jemand mit GDB aus?

Jetzt mitmachen!

Teilen