Kann mal bitte jemand auflisten welche Patches aktuell sind? Dann würde ich die gegen Abend in einem neuen Branch mal einbauen.
Ich denke
#83 vnsiserver-gcc12.diff.txt
und
#115 responsepacket_realloc_3.diff.txt
Sollten jetzt schon einmal in dein repo. Aber bitte erst taggen, wenn mehr user input kommt.
Hab ich jetzt mal übernommen. Wobei letzterer Patch noch etwas wie "Testen ob es hilft" wirkt. Aber ich habe das im Post auch so verstanden das es genau darum erstmal geht. Um das Problem auf diese Stelle einzugrenzen.
Weitere Patches dann bitte ausgehend vom Stand hier: https://github.com/vdr-projects/vdr-plugin-vnsiserver
#83 vnsiserver-gcc12.diff.txt
Der sollte auf jeden Fall rein. (War aber in Beitrag #81 
.)
Der Patch behebt nachvollziehbare Fehler auf nachvollziehbare Weise.
Wobei letzterer Patch noch etwas wie "Testen ob es hilft" wirkt. Aber ich habe das im Post auch so verstanden das es genau darum erstmal geht. Um das Problem auf diese Stelle einzugrenzen.
So ist es.
Der Patch hätte die Ursache wenn nur durch Zufall behoben, hätte aber die Symptome (=Abstürze) beseitigen oder verringern können.
Ich habe einfach einen großzügigen 80Byte-Puffer am Ende des Speicher-Blocks für das "responsepacket" eingefügt, so dass etwas Raum für Fehler bleibt.
Des weiteren vergrößere ich den jetzt in Schritten zu 512Byte(+x), nicht wie bisher in mini Schritten (zB. 4Byte für einen hinzugefügten uint32_t). Das spart eine Menge realloc() Aufrufe in der for-Schleife.
Zumindest eine dieser Maßnahmen hätte was gegen die Abstürze bringen können.
Der Hintergedanke war:
Die Speicherverwaltung versucht die Threads in getrennte Speicherbereiche zu legen, um globale mutex zu sparen und damit die Leistung zu steigern. Der "tcache" ist auch thredbezogen.
Garantiert ist das zwar nicht, die Chance, dass ein Thread seine Speicherbereiche selbst zerstört sollte statistisch normalerweise aber höher sein, als dass es ein anderer Thread macht.
Zumal es hier ja auch immer im gleichen Thread an fast der gleiche Stelle zu schlägt.
Da das aber nicht geklappt hat, ist das "responsepacket" wohl erstmal raus.
Also mit dem neuen Patch responsepacket_realloc_3.diff.txt und dem Patch aus #81 erhalte ich auch mit der Compiler Option -O3 keine Warnung mehr.
Bitte nochmal nur mit dem Patch aus #81 probieren (nur ob die Warnung kommt reicht).
An meinem kann das mit der Warnung nämlich eigentlich nicht liegen.
(Ich wüsste zumindest nicht, wie ich das angestellt haben könnte 
.)
responsepacket_realloc_3.diff.txt sorgt auch dafür, dass malloc() seltener aufgerufen wird, da der buffer um mehr als 'by' vergrößert wird.
Das alleine schon ist gut.
Mir fällt gerade auf, dass diese Zeilen in vdr selbst nicht ok sind.
sources.c:55
cString cSource::ToString(int Code)
{
char buffer[16];
char *q = buffer;
*q++ = (Code & st_Mask) >> 24;
if (int n = Position(Code)) {
q += snprintf(q, sizeof(buffer) - 2, "%u.%u", abs(n) / 10, abs(n) % 10); // can't simply use "%g" here since the silly 'locale' messes up the decimal point
*q++ = (n < 0) ? 'W' : 'E';
}
*q = 0;
return buffer;
}Wenn snprintf hier einen Fehler hat, dann wird snprintf einen negativen return code geben.
Dokumentation: "If an encoding error occurs, a negative number is returned."
Danach würde u.U. die nächste Zeile an eine falsche Stelle im Speicher schreiben:
*q++ = (n < 0) ? 'W' : 'E';Ich glaube, so wäre korrekter
cString cSource::ToString(int Code)
{
char buffer[16];
char *q = buffer;
*q++ = (Code & st_Mask) >> 24;
if (int n = Position(Code)) {
int l = snprintf(q, sizeof(buffer) - 1, "%u.%u", abs(n) / 10, abs(n) % 10); // can't simply use "%g" here since the silly 'locale' messes up the decimal point
if (l < (sizeof(buffer) - 1) && l > 0) {
q += l;
*q++ = (n < 0) ? 'W' : 'E';
}
}
*q = 0;
return buffer;
}Aber wie kann bei %u ein encoding error auftauchen - das sind doch nur Zahlen.
Klingt wie Ariadne4-Software auf Ariadne5 damals ... 
Ariane 5 ist wegen floating point cast abgestürzt.
Ok, so etwa lt. Wikipedia "The greater values of BH caused a data conversion from a 64-bit floating point number to a 16-bit signed integer value to overflow and cause a hardware exception.[5]".
Jedenfalls ein Overflow ...
Auch nach entfernen von responsepacket_realloc_3.diff.txt gibt es keine Warnungen mehr.
Dann passt es ja.
Auf der Suche, ob weiter "vorne" im Thread was falsch gelaufen ist, bin ich vielleicht auf was gestoßen:
Gleich nach StartThread kommt immer dieses:
#15 0x00007fe729ec4950 in cVNSIClient::Action (this=0x7fe700000ef0) at vnsiclient.c:103Der Code dazu:
std::unique_lock<std::mutex> lock( m_QueueMutex );
if ( m_QueueCondVar.wait_for(lock, std::chrono::milliseconds(100), [this]()
{
return m_Queue.size() > 0;
}))
{
auto command = std::move(m_Queue.front());
m_Queue.pop_front();
lock.unlock();
command->execute(*this);Man beachte besonders Zeile 99: Das ganze Objekt, mit dem wir es hier zu tun haben, wurde wurde mittels std::move "verschoben".
Genauer gesagt, wird das Objekt aus der Liste heraus "kopiert" und das in der Liste dann gelöscht. Das std::move erlaubt es dem Compiler aber auch move operator/constructor dazu zu verwenden.
Prinzipiell ist daran nichts auszusetzen, aber könnte das nicht die Verbindung zum neu eingeführten move constructor beim cString sein?
Eventuell wurde bislang immer implizit eine Kopie von "Irgendwas" erzeugt und jetzt nicht mehr, was dann zu den Abstürzen führt?
Wie genau da jetzt das cString vom VDR rein spielt, bin ich nicht sicher. Die Objekte vom Typ
ICommandSharedPtr&, hier konkret cRequestPacket, enthalten aber einen String der Form uint8_t* userData. Instanziiert werden die fraglichen Objekte hier:
m_Queue.push_back( command );An beiden Stellen ist aber vdr/tools.h via #include <vdr/channels.h> verfügbar, es könnte also.
Ausserdem gibt es im requestpacket noch so eine verdächtige, auskommentierte Funktion:
// If you call this, the memory becomes yours. Free with free()
//uint8_t* getData();Das sieht mir so aus, als ob da mal was angedacht war.
Ich nehme jetzt einfach testweise mal das std::move raus, um die Kopie zu erzwingen. (Bitte auf den neueste GIT-Stand anwenden.)
Mal sehen was passiert, der Compiler winkt das bei mir zwar ohne Beanstandungen durch, aber ob es wirklich geht bin ich echt nicht sicher.
Das ist erstmal auch nur ein Versuch, eine echte Lösung wäre das sowieso noch nicht.
Vielleicht wäre es hier sinnvoller, std::swap zu verwenden, dann ist der Pointer in der queue definitiv leer und kann ohne Nebenwirkungen weg.
So etwas wie (ungetestet..)
while (Running())
{
try
{
std::unique_lock<std::mutex> lock( m_QueueMutex );
if ( m_QueueCondVar.wait_for(lock, std::chrono::milliseconds(100), [this]()
{
return m_Queue.size() > 0;
}))
{
std::shared_pointer<ICommand> command; // shared ptr w. no managed object
std::swap(command, m_Queue.front()); // command = m_Queue[0], m_Queue[0] = NULL;
m_Queue.pop_front(); // now, remove m_Queue[0]
lock.unlock();
command->execute(*this);
// command should be destroyed automatically here,
// as ref count goes to zero.
}
}
catch ( const std::exception& error )
{
ERRORLOG( "Client error: '%s'. Dropping client", error.what() );
break;
}
catch ( ... )
{
ERRORLOG( "Client error: 'Undetermined exception'. Dropping client" );
break;
}
}Vielleicht wäre es hier sinnvoller, std::swap zu verwenden, dann ist der Pointer in der queue definitiv leer und kann ohne Nebenwirkungen weg.
Das klingt, als ob es ein brauchbarer Lösungs- oder Verbesserungsansatz wäre.
(Das Konstrukt mit dem std::move aus einer Queue wird mehrfach verwendet.)
Man müsste aber mal schauen, was das std::swap genau macht. Nachher sind es nur 3 moves und ein temporärer Pointer, dann hätte man nichts gewonnen.
Die Objekte in der m_Queue sind auch intern ziemlich unterschiedlich. Es erben lediglich alle von ICommandSharedPtr. Das kann tückisch sein, was mit dem einen Objekt-Typ geht, kann beim Anderen zu Fehlern führen
Ich hatte, ehrlich gesagt, aber noch gar nicht soweit gedacht, sondern erstmal nur versucht das vermutete, alte Verhalten zu emulieren.
Und das mit möglichst wenig Aufwand und nachdenken, meine Freizeit ist halt leider auch begrenzt...
Wenn es was gebracht hätte, hätte man ja weiter darüber nachdenken können, was da los ist.
Der Fehler ist auch nach wie vor an etwa der gleichen Stelle, diesmal trifft es aber ein free().
Interessant ist, dass es diesmal im Moveoperator von cString auftritt:
#8 0x0000000000553c96 in cString::operator= (this=this@entry=0x23ddfe8, String=...) at tools.c:1111Wenn ich das this=this richtig interpretiere, ist es diesmal auch eine nicht abgefangene Selbstzuweisung gewesen.
Wenn das stimmt, sollte man den Test nochmal wiederholen. Zusätzlich mit dem Patch aus #48 im VDR.
Crash 2 ist wieder mal der alte Bekannte cChannel::Name.
Crash 1 müsste wieder in der Zeile mir caids = cString::sprintf("%s%d;", (const char*)caids, caid); sein. Nur da passt für mich die Aufruf-Reihenfolge.
Interessant ist hier aber, dass es direkt nach einer Fehlermeldung geknallt hat (Zeile 1180):
if (!fmt || vasprintf(&buffer, fmt, ap) < 0) {
esyslog("error in vasprintf('%s', ...)", fmt);
buffer = strdup("???");
}RHS Das wäre eventuell hilfreich, wenn Du die noch finden könntest.
Da man an den Punkt eigentlich nie gelangen sollte, könnten die Informationen Aufschluss geben, was da schief läuft.
Da die Crashs anscheinend recht schnell auftreten, wäre es möglich das mal nur mit einem KODI-Client zu versuchen?
Das wäre mal interessant, ob die Crashs da auch auftreten.
Irgendwie ist schon merkwürdig, dass die Fehler immer nur in dieser einen Funktion und im Zusammenhang mit den Channels auftreten.
Das EPG wird durch ein sehr ähnliches Konstrukt eingelesen und da gibt es nie Ärger.
Verwendet jemand zufällig das SAT>IP-Plugin in Verbindung mit ShowChannelNamesWithSource == 2 (Das ist mit Anzeige der SAT-Position.)?
Nur um sicher zu stellen, dass es nicht daran liegt.
Zum Testen sollte es reichen das zu aktivieren und die ein- zwei-mal die Kanalliste durch zu scrollen.
Mit einer DVB-Karte werde ich es die Tage mal testen, aber mit SAT>IP kann ich es leider nicht.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!