Hi,
in dem Fork fehlen noch die Änderungen, die nach dem 30.Mai 2021 in rofafor/master kamen.
Die müssen noch per Hand nachgepflegt werden, weil sie mit anderen Änderungen kollidieren. Für die Anwendung in w_scan_cpp hatten die keinen Vorteil, als stand-alone Plugin vielleicht.
Die Meldung besagt, dass die SDT eines anderen (wohl des vorherigen) Transponders empfangen wird und etwas beim Umschalten geklemmt hat.
Klingt nach Astra 19.2 von den IDs her.
#1 0x00007f9fe0041176 __GI_raise (libc.so.6 + 0x41176)
#2 0x00007f9fe0028917 __GI_abort (libc.so.6 + 0x28917)
heißt aber AFAIK, dass das geplant aborted wurde, also dass ggf. das kaputt ist, was in den vasprintf gesteckt wurde.
in vasprintf wird malloc aufgerufen, soll ja ein neuer const char* zurück gegeben werden. malloc versucht sich ein neues Häppchen Speicher aus dem tcache zu holen (sind ja nur wenige bytes), aber stolpert dabei und printet einen Fehler + ruft wohl abort() aus stdlib.h auf.
Dass bei dir noch die Warnung auftritt, aber bei den anderen nicht, habe ich nicht verstanden.
Aber die Warnung ist nur ein weiteres Problem.
Und es knallt wieder in cString::sprintf() bei vasprintf
Die PIDs in der xspf sind service ID, Audiio, Video und die normalen DVB SI tables.
So wie es ausschaut, hat tvheadend Probleme beim Transcodieren (nicht genug CPU power dort?) oder Verpacken des Streams, deswegen bekommst du wohl die Daten häppchenweise.
Vielleicht sind es cString::sprintf() und cString::vsprintf(), die nicht threadsafe sind.
Zu vasprintf() gibt es Hinweise, dass die Funktion nur dann threadsafe ist, wenn sich die locale nie ändert.
Ich würde mal vlc plus tvheadend testen. Einfach die datei im Anhang in xspf umbenennen und dann mit vlc öffnen.
SHF: Genau die gleiche Idee. Die macros machen auch nicht viel anderes.
Wollen wir mit deinem oder meinem Patch weitermachen?
Mir egal, Hauptsache gleicher Code und es ist absolut sicher, dass der Lock aus dem Spiel ist.
@Zeilennummern, ich nutze einen online c++ demangler zur Lesbarkeit und hangele mich dann Zeile für Zeile durch den code, beginnend ab der ersten im Core. Setzt voraus, dass man *genau* den code hat, vdr und plugin.
habe ich die channels.conf per w_scan_cpp erzeugt und er hat auch den einen von mir erzeugten Kanal im channels.conf Format ausgegeben:
HDMI:114000:I0C0M256:C:6900:256=36:257=@15:0:0:1:0:1:0
Frage: passt das? Frequenz stimmt schonmal, bei den restlichen xPIDs bin ich mir nicht sicher.
Das bedeutet, dass das satip Plugin auf dem Computer auf dem du w_scan_cpp ausgeführt hast, ebenso erfolgreich funktioniert hat.
w_scan_cpp nutzt intern das satip Plugin.
Ich glaube, wenn das funktioniert, dann ist diese config auf der VDR Seite für das satip Plugin ok. Zumindest hast du Empfang und die DVB SI Tables kommen an.
Der Stream meldet sich H.265 mit Audio ISO/IEC 13818-7 Audio with ADTS transport.
Mein Fehler.
Der folgende patch ändert processCHANNELS_GetChannels() so,
dass
- Channels auf NULL geprüft wird
- cStateKey::Remove() nur ausgeführt wird, wenn Channels != NULL
- vdr < 1.3.1 aus der Funktion entfernt wird und die Zeilen im if eingerückt werden.
Damit ist der Lock ganz genau so, wie hier beschrieben.
Aber am eigentlichen Problem geht das immer noch vorbei.
M-Reimer , würdest du die Patche in diesem thread deinen fork aufnehmen? Wäre gut, wenn das zentral ist.
Es knallt immer wieder in vnsiclient.c:1148 und den Zeilen danach, kurioserweise immer wieder
cVNSIClient::processCHANNELS_GetChannels(), dann cChannel::Name(), dann cString::sprintf(), in cString::sprintf() wird vasprintf() aufgerufen, dann schafft es vielleicht nocht die Fehlermeldung ins log, bevor der Prozess beendet wird. Das sind dann die Zeilen im for loop in
cVNSIClient::processCHANNELS_GetChannels #0 0x00007f01d36949ec __pthread_kill_implementation (libc.so.6 0x949ec)
#1 0x00007f01d3641176 __GI_raise (libc.so.6 0x41176)
#2 0x00007f01d3628917 __GI_abort (libc.so.6 0x28917)
#3 0x00007f01d36297e8 __libc_message_impl (libc.so.6 0x297e8)
#4 0x00007f01d369f3c7 malloc_printerr (libc.so.6 0x9f3c7)
#5 0x00007f01d36a3cdc tcache_get_n (libc.so.6 0xa3cdc)
#6 0x00007f01d36861c8 __vasprintf_internal (libc.so.6 0x861c8)
#7 0x000000000053507d cString::sprintf(char const*, ...) (vdr 0x13507d)
#8 0x000000000047fb36 cChannel::Name() const (vdr 0x7fb36)
#9 0x00007f01d35b2edd cVNSIClient::processCHANNELS_GetChannels(cRequestPacket&) (libvdr-vnsiserver.so.2.6.6 0x3aedd)
#10 0x00007f01d35b9485 cVNSIClient::processRequest(cRequestPacket&) (libvdr-vnsiserver.so.2.6.6 0x41485)
#11 0x00007f01d35b96ef cVNSIClient::visit(cRequestPacket&) (libvdr-vnsiserver.so.2.6.6 0x416ef)
#12 0x00007f01d35c4aa8 cRequestPacket::execute(ICommandVisitor&) (libvdr-vnsiserver.so.2.6.6 0x4caa8)
#13 0x00007f01d35afdc5 cVNSIClient::Action() (libvdr-vnsiserver.so.2.6.6 0x37dc5)
#14 0x000000000052a536 cThread::StartThread(cThread*) (vdr 0x12a536)
#15 0x00007f01d3692bb2 start_thread (libc.so.6 0x92bb2)
#16 0x00007f01d371400c __clone3 (libc.so.6 0x11400c)Auffällig ist auch, dass zwei threads in der gleichen Funktion cVNSIClient::processCHANNELS_GetChannels sind.
Hast du auch neue Backtraces, z.B. von automatisch geschriebenen cores?
@warnings:
streamer.c:57:17: warning: member ‘cLiveStreamer::m_Event’ is used uninitialized [-Wuninitialized]
57 | , m_VideoInput(m_Event)
| ^~~~~~~Der Constructor von m_VideoInput wird mit dem lokalen class member m_Event aufgerufen,
aber m_Event ist selbst noch nicht sicher erzeugt. Deswegen erst den m_Event constructor aufrufen und _dann_ den Constructor von m_VideoInput.
Falsche Reihenfolge.
g++ hat recht.
Hier wird für jeden member von (*whitelist) eine lokale Kopie innerhalb des for loop angelegt.
Das kostet Speicher und seeeehr viel Zeit, und hofft darauf, dass die Kopie wirklich alle Daten kopiert, etc.
channelfilter.c: In member function ‘void cVNSIChannelFilter::StoreWhitelist(bool)’:
channelfilter.c:188:23: warning: loop variable ‘i’ creates a copy from type ‘const cVNSIProvider’ [-Wrange-loop-construct]
188 | for (const auto i : *whitelist)
| ^
channelfilter.c:188:23: note: use reference type to prevent copying
188 | for (const auto i : *whitelist)
| ^
| &videoinput.c:468ff
Hier gibt es gleichzeitig mehrere Probleme.
Zum einen wird von jedem member von sPool (seehr laaangsam) eine lokale Kopie im Geltungsbereich des for loop angelegt.
Das alleine garantiert nicht, dass in der Zwischenzeit aber nicht der 'echte' cDummyReceiver nicht zerstört wurde -> race.
Und zusätzlich könnte auch der shared pointer dabei sein zerstört zu werden 'expired'. Aber selbst wenn nicht, kann ja 'recv' immer noch ein NULL pointer sein.
Eigentlich haben die gcc Entwickler wirklich gute Arbeit geleistet.
Code rausgefischt mit Warnungen, der schwer zu lesen ist..
inlined from ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’ at videoinput.c:469:28:
/usr/include/c++/13/bits/atomic_base.h:505:31: warning: ‘unsigned char __atomic_load_1(const volatile void*, int)’ writing 1 byte into a region of size 0 overflows the destination [-Wstringop-overflow=]
505 | return __atomic_load_n(&_M_i, int(__m));
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
In static member function ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’:
cc1plus: note: destination object is likely at address zeroIch fürchte ja das wird damit noch nicht erwischt sein, ich hoffe dass jmd testet und mit logs berichtet.
Aber vllt eine erste Verbesserung.
Wunderbar!
Ich frage mich jedesmal, welchen Lack damals die C/C++ Entwickler gesoffen haben, als sie float<->string(char*) konversationen von der lokalen Sprache abhängig machten.
Ich würde allerdings diese Art von Stolperstellen gerne an einer zentralen Stelle in librepfunc bündeln,
damit ich nicht immer wieder darüber stolpere.
Ich schau mir das an und würde dich eventuell nach Tests oder Änderungen fragen.
Mit 13.2.0 kann ich keine Warnungen mehr produzieren.
Eine Möglichkeit wäre
w_scan_cpp -fc --satip > channels.conf
Aber das wird nur dann funktionieren, wenn tvheadend sich wie ein normaler SAT>IP server verhält.
Die zweite Möglichkeit wäre, einfach einen bekannten Kanal in die channels.conf per Hand einzutragen, mindestens müssen Frequenz, Symbolrate und Modulation stimmen. PIDs sind egal.
Probiert mal damit.
Damit kann das Problem weiter eingeengt werden
gcc > 11.1.0 && gcc <= 12.3.0