Compile Warnings in vnsiserver

Dann war's das wohl erstmal mit Kodi und VDR. Das einzige das ich bestätigen kann, ist, dass ich diese Warnings auch sehe.

g++ -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -std=c++11 -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"vnsiserver"' -DVNSI_SERVER_VERSION='"1.8.3"'  -o StatusCommands.o StatusCommands.c
In file included from /usr/include/c++/13.2.1/bits/shared_ptr_atomic.h:33,
                 from /usr/include/c++/13.2.1/memory:81,
                 from videoinput.h:27,
                 from videoinput.c:27:
In member function ‘std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool]’,
    inlined from ‘std::atomic<bool>::operator bool() const’ at /usr/include/c++/13.2.1/atomic:87:26,
    inlined from ‘bool cDummyReceiver::BeenDetached()’ at videoinput.c:428:31,
    inlined from ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’ at videoinput.c:468:28:
/usr/include/c++/13.2.1/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 zero
In member function ‘std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool]’,
    inlined from ‘std::atomic<bool>::operator bool() const’ at /usr/include/c++/13.2.1/atomic:87:26,
    inlined from ‘bool cDummyReceiver::BeenDetached()’ at videoinput.c:428:31,
    inlined from ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’ at videoinput.c:468:28:
/usr/include/c++/13.2.1/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=]
In static member function ‘static std::shared_ptr<cDummyReceiver> cDummyReceiver::Create(cDevice*)’:
cc1plus: note: destination object is likely at address zero

Und damit bin ich mit meinem Latein auch schon am Ende. Absolut Null Ahnung was der Compiler damit sagen will.

Scheint was schwierigeres zu sein. Vielleicht hilft es, stückweise Infos zu sammeln. Mit gcc 11.1 gibt es diese Warnungen nicht.

Der Compiler sagt, soweit ich lesen kann ..

- es gibt in videoinput.c eine Klasse cDummyReceiver

- diese Klasse hat eine member Funktion bool BeenDetached() in videoinput.c Zeile 428, welches den private member std::atomic<bool> m_BeenDetached zurückgibt. Also ist diese Funktion wohl shared zwischen mehreren threads.

Der compiler inlined das wegen Optimisation, so dass der private member std::atomic<bool> m_BeenDetached direkt zurück gegeben wird.

- mit diesem member m_BeenDetached gibt es wohl ein Problem in cDummyReceiver::Create(cDevice *), damit wäre man dann wohl bei Zeile 468

    if (!recv->BeenDetached() && recv->Device() == device)

Zwei Fragen wären interessant, der loop geht über alle cDummyReceiver in s_Pool:

for (auto p : s_Pool)

aber evtl wäre auch möglich um Kopien der member von s_Pool zu vermeiden

for (auto& p : s_Pool)

Ich habs nicht ausprobiert, ich nutze vnsi nicht.

Irgendwie endet der lesbare code in Zeile 467

auto recv = p.lock();

Ich verstehe nicht, woher der member lock() kommt.

Das "p" ist hier definiert:

vdr-plugin-vnsiserver/videoinput.c at 57e4c71faae7414e15d3e36c4cfb4e7d7f518f72 · vdr-projects/vdr-plugin-vnsiserver

VDR plugin to handle XBMC clients. Contribute to vdr-projects/vdr-plugin-vnsiserver development by creating an account on GitHub.

github.com

Und wenn man mal nach diesem "weak_ptr" sucht, dann findet man auch das "lock"

std::weak_ptr<T>::lock - cppreference.com

Vielleicht hätte man beim Entwickeln von vnsiserver nicht ganz so abgrundtief in die C++-Trickkiste greifen müssen. Dann wäre der Code vielleicht sogar lesbar geblieben

std::weak_ptr<T>

A shared_ptr which shares ownership of the owned object if std::weak_ptr::expired returns false. Else returns default-constructed shared_ptr of type T.

Möglicherweise ist das Object gelöscht worden, so dasss der return value 'false', aka '0' ist. Aber damit kenne ich mich nicht aus.

Ich habe mal noch eine Weile gesucht und immer wieder die Info gelesen, dass diese Warning wohl schon mehrfach ein "False Positive" war. Ich würde mal wagen zu behaupten das diese Warnung nicht 100%ig sicher die Ursache für den seit neuestem auftretenden Crash ist:

malloc(): unaligned tcache chunk detected

Und selbst mit einem Backtrace könnte ich die Ursache selbst nicht finden. Das Kauderwelsch in Backtraces konnte ich eigentlich noch nie lesen.

Alles ein bisschen ernüchternd. Da VNSI eigentlich echt gut funktioniert hatte, hatte ich Hoffnung, dass es reicht das immer nur an neue VDR-Versionen anzupassen. Das bis vor kurzem funktionierender Code dann plötzlich nicht mehr funktioniert stellt für mich das ganze Konzept "VDR" in Frage.

Wäre schön, mal den ganzen gdb bt zu sehen.

wirbel Wäre für mich schon eine etwas größere Sache weil ich alles selbst kompiliere. Und ich habe eigentlich auch nur ein System das für einen Test in Frage kommt, welches gleichzeitig das Produktivsystem ist. Da ich bei Arch eigentlich nur eine Option habe was Compiler angeht (gcc 13.2.1) und damit wohl ziemlich sicher mein Produktivsystem lahmlege, würde ich erstmal abwarten ob sich jemand anderes findet der einen Backtrace bauen kann.

Selbe Situation hier.

Ich habe wie Warnung gerade auch in den Buildlogs des vnsiserver für Ubuntu 24.04 gesehen - da ich immer Debug-Pakete mit erzeugen lasse, sollte es nicht allzu schwer sein an einen Backtrace zu kommen.

RHS: Was muss man den tun, um so einen Crash möglichst schnell zu provozieren? Für mich wäre es am einfachsten einen headless VDR auf einem Ubuntu 24.04 aufsetzen, dem einen Tuner zu geben und dann einen KODI-Client mit vnsi PVR-Addon von einem anderen Rechner darauf zugreifen lassen.

Ich mach das meist in gdb. Sowas wie

ulimit -c unlimited
gdb --args <deine normale vdr befehlszeile hier mit allen Plugins>

Danach mit der Taste r den Prozess starten und auf den Crash warten.

Die letzten Zeilen vor dem crash bekommst du dann im gdb Fenster mit

bt full

In meinem debian mache ich:

sudo coredumpctl list
sudo coredumpctl debug <PID>   (PID aus der Liste)
bt full

So kann ich auch ein bt all machen, wenn der VDR Server "zufällig" abgestürzt ist.

Leider geht das in Ubuntu (meines Wissens) anders. In SuSE vermutlich wieder anders ...

Ich mache das unter Suse wie folgt

cd /home/<Dein User>
ulimit -c unlimited
gdb /usr/local/bin/vdr -c core
set logging file backtrace.txt
set logging on
run
▪ nach dem Absturz
bt full

Stefan

Quote from MarkusE

Leider geht das in Ubuntu (meines Wissens) anders.

Da kann man sich auch systemd-coredump nachinstallieren, wenn man das nicht über das vorinstallierte apport machen will.

Quote from M-Reimer

Das "p" ist hier definiert:

Bin ich der Einzige, der die for-Schleife in Zeile 456 merkwürdig findet?

Genauer gesagt, das autp p und das aus mehreren Gründen.

- p existiert, wie gesagt, bereits.

- Eine auto Variable müsste doch eigentlich gleich initialisiert werden?

Entweder ist das ein genialer C++-Hack, den ich nicht verstehe, oder da ist was faul.

Ehrlich gesagt, wüsste ich jetzt auch nicht sicher, was bei dem Konstrukt raus kommt.

Gefühlt würde ich aber mal auf eine uninitialisiertes int p in der Schleife tippen.

Ich hätte das auto p jedenfalls einfach weg gelassen, also for ( : s_Pool) oder gleich while (s_Pool) verwendet.

for (auto p : s_Pool) {

ist das gleiche wie:

for (auto p = s_Pool.begin(); p != s_Poll.end(); p++) {

siehe z.B. hier.

Quote from SHF

p existiert, wie gesagt, bereits.

Aber nur in dem Closure davor für das erase - remove_if Idiom (https://www.geeksforgeeks.org/erase-remove-idiom-in-cpp/), oder? Und selbst wenn müsste die Deklaration für die range-based for loop (https://en.cppreference.com/w/cpp/language/range-for) eine vorhandene Variable überdecken (shadowing).

p müsste dann in der range-base for loop eine Kopie des jeweils durchlaufenen std::weak_ptr<cDummyReceiver> aus dem Vector sein, was für mich so aussieht, als ob das den Schutz, den man durch das Locking erreichen will, aushebeln könnte, weil die beiden weak_ptr das gleiche Objekt verwalten - wäre da ein &p nicht besser?

Quote from SHF

Ich hätte das auto p jedenfalls einfach weg gelassen, also for ( : s_Pool) oder gleich while (s_Pool) verwendet.

Aber das p wird doch gebraucht, um den Receiver aus dem weak_ptr zu bekommen, der von der Methode ggf. zurückgegeben werden soll: https://github.com/vdr-project…/master/videoinput.c#L467

Quote from seahawk1986

Aber nur in dem Closure davor für das erase - remove_if Idiom [...]

Stimmt, da habe ich nicht aufgepasst. Das hat mich aufs Glatteis geführt.