restfulapi: SIGSEGV, Segmentation fault

Zabrimus · 29. November 2015

Da ich nicht auf den Bugtracker komme und auch im Github irgendwie keine Möglichkeit finde, einen Issue zu melden, versuche ich es hier.

Installiert ist die aktuelle Git-Version des Plugins (0.2.5.5).

Aufruf mit http://<server>:<port>/info.json Resultat ist ein SIGSEGV und ein Neustart des bzw. der entsprechenden VDR Instanzen (mit oder ohne DVB devices, streamdev server oder client):

Der BT sieht so aus:

Code

program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffa1ffb700 (LWP 3414)]
cChannel::Name (this=this@entry=0x0) at channels.c:129
129       return name;
(gdb) bt
#0  cChannel::Name (this=this@entry=0x0) at channels.c:129
#1  0x00007ffff3a56503 in InfoResponder::getDeviceSerializeInfo (this=this@entry=0x7fff9400caf0, index=index@entry=2) at info.cpp:251
#2  0x00007ffff3a57bc5 in InfoResponder::replyJson (this=0x7fff9400caf0, se=...) at info.cpp:118
#3  0x00007ffff3a55387 in InfoResponder::reply (this=0x7fff9400caf0, out=..., request=..., reply=...) at info.cpp:27
#4  0x00007ffff34a46b0 in cxxtools::http::Socket::doReply() () from /usr/lib/libcxxtools-http.so.9
#5  0x00007ffff34a3a4a in cxxtools::http::Socket::onInput(cxxtools::StreamBuffer&) () from /usr/lib/libcxxtools-http.so.9
#6  0x00007ffff378408e in cxxtools::StreamBuffer::onRead(cxxtools::IODevice&) () from /usr/lib/libcxxtools.so.9
#7  0x00007ffff3759dde in cxxtools::IODeviceImpl::checkPollEvent(pollfd&) () from /usr/lib/libcxxtools.so.9
#8  0x00007ffff379a533 in cxxtools::net::TcpSocketImpl::checkPollEvent(pollfd&) () from /usr/lib/libcxxtools.so.9
#9  0x00007ffff375997d in cxxtools::IODeviceImpl::wait(unsigned long) () from /usr/lib/libcxxtools.so.9
#10 0x00007ffff34a7acf in cxxtools::http::Worker::run() () from /usr/lib/libcxxtools-http.so.9
#11 0x00007ffff378dc94 in ?? () from /usr/lib/libcxxtools.so.9
#12 0x00007ffff798d0ca in start_thread (arg=0x7fffa1ffb700) at pthread_create.c:309
#13 0x00007ffff634006d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
(gdb) quit

Alles anzeigen

Ich denke, ich werde die nächsten Tests nicht mehr mit den Produktions-VDR machen

Zabrimus

hannemann · 29. November 2015

Hi,

hast du noch weitere Infos zur Umgebung? VDR Version usw.

Zabrimus · 29. November 2015

Kein Problem.

VDR Version ist in allen Fällen ein VDR 2.2.0. Passiert ist es auf folgenden Systemen:

1. Debian Jessie, 8 DVB Devices, Streamdev Server (headless)
2. Debian Jessie, 0 DVB Devices, reiner Streamdev Client (headless)
3. Raspbian, 0 DVB Devices, reiner Streamdev Client (TV)

Der Softwarestand aller Server/Client ist (endlich) identisch, die Hardware ist schon relativ unterschiedlich.

Das Plugin will wohl den Channelname lesen oder verarbeiten. Dann könnte evt. das Plugin suspendoutput mit eine Ursache sein - reine Mutmaßung.

Zabrimus

mini73 · 29. November 2015

Ist da ein Pointer auf einen Kanal NULL? Sieht fast danach aus.

Lars

mini73 · 29. November 2015

https://github.com/yavdr/vdr-p…blob/master/info.cpp#L251
Da muss wohl eine "chan != NULL" Prüfung hin.

Lars

hannemann · 29. November 2015

Klingt plausibel...

Zabrimus: kannst du das bitte mal testen?

Zabrimus · 5. Dezember 2015

So endlich Zeit gefunden...

Eine einfache Bedingung reicht tatsächlich aus, den Segfault zu verhindern:

Diff

--- info.cpp.original   2015-12-05 08:23:09.094340121 +0100
+++ info.cpp    2015-12-05 08:25:40.889827608 +0100
@@ -243,20 +243,22 @@
   int adapter = -1;
   int frontend = -1;
 
   string type = "n.a.";
   int channelNr = -1;
   bool live = false;
 
   if (dev->ProvidesSource(cSource::stCable) || dev->ProvidesSource(cSource::stSat) || dev->ProvidesSource(cSource::stTerr) || dev->ProvidesSource(cSource::stAtsc)) {
-      channelName = (string)chan->Name();
-      channelId = (string)chan->GetChannelID().ToString();
-      channelNr = chan->Number();
-      live = channelNr == StatusMonitor::get()->getChannel();
+      if (chan) {
+          channelName = (string)chan->Name();
+          channelId = (string)chan->GetChannelID().ToString();
+          channelNr = chan->Number();
+          live = channelNr == StatusMonitor::get()->getChannel();
+      }
 
       hasCi = dev->HasCi();
       signalStrength = dev->SignalStrength();
       signalQuality = dev->SignalQuality();
       adapter = dev->Adapter();
       frontend = dev->Frontend();
       type = (string)dev->DeviceType();
   }

Alles anzeigen

Dev-VDR1 ohne Patch stürzt reproduzierbar ab, Dev-VDR2 (1:1 Kopie von Dev-VDR1) mit Patch macht keine Probleme.

Zabrimus

hannemann · 5. Dezember 2015

Cool... Vielen Dank.

Ich wollte auch schon längst einen Patch erstellt haben, bin aber noch nicht dazu gekommen.

Verdammtes Weihnachten

t0mcat · 11. Februar 2016

Hi zusammen,

habe ein ähnliches Problem. Beim Aufruf von

http://<server>:<port>/recordings/.json bzw. http://<server>:<port>/recordings.json

stürzt VDR mit einem Segfault ab:

vdr: [16954] restfulapi: requested recording not found (read)
kernel: [5761865.121185] vdr[16954]: segfault at 6900000065 ip 00007f0469362730 sp 00007f044dff0ac0 error 4 in libgcc_s.so.1[7f0469353000+15000]

Verwende ebenfalls vdr-2.2.0 und die aktuellste Plugin Version aus git 0.2.5.5

Der SegFault passiert, sobald auch nur ein einziges recording vorhanden ist.. wenn das video.00 VZ leer ist, kommt diese korrekte Antwort:

{"recordings":[],"count":0,"total":0}

Hat jmd. ne Idee?

Viele Grüße

seahawk1986 · 11. Februar 2016

Kannst du einen richtigen Backtrace erzeugen? Welche Version von tntnet und cxxtools nutzt du? Ich meine vor der 2.2.0 gab es Probleme mit dem Unicode-Handling.

t0mcat · 11. Februar 2016

Version von tntnet ist: 2.1-2.9
Version von libcxxtools: 2.1.1

Versuche das mit dem Backtrace gerade hinzubekommen (hab ich noch nie gemacht, muß ich gestehen )

1.) Versuch:
ulimit -c unlimited
vdr ohne -d gestartet
Fehler provoziert:
*** stack smashing detected ***: /usr/local/bin/vdr terminated
Speicherzugriffsfehler (Speicherabzug geschrieben)

ABER: Finde nirgendwo den core, weder im aktuellen, noch im /tmp Verzeichnis

2.) Versuch:
vdr ohne -d gestartet
gdb --pid <vdrpid>
continue

Fehler provoziert
Im GDB:

Code

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f219b7f6700 (LWP 3239)]
0x00007f21b913d730 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
(gdb) 
Continuing.
[Thread 0x7f21b1649700 (LWP 3219) exited]
[Thread 0x7f21abfff700 (LWP 3221) exited]
[Thread 0x7f21ab7fe700 (LWP 3222) exited]
[Thread 0x7f21aaffd700 (LWP 3223) exited]
[Thread 0x7f21aa7fc700 (LWP 3224) exited]
[Thread 0x7f21a9ffb700 (LWP 3226) exited]
[Thread 0x7f21a97fa700 (LWP 3228) exited]
[Thread 0x7f21a8ff9700 (LWP 3229) exited]
[Thread 0x7f219ffff700 (LWP 3230) exited]
[Thread 0x7f219f7fe700 (LWP 3231) exited]
[Thread 0x7f219effd700 (LWP 3232) exited]
[Thread 0x7f219e7fc700 (LWP 3233) exited]
[Thread 0x7f219dffb700 (LWP 3234) exited]
[Thread 0x7f219d7fa700 (LWP 3235) exited]
[Thread 0x7f219cff9700 (LWP 3236) exited]
[Thread 0x7f219c7f8700 (LWP 3237) exited]
[Thread 0x7f219bff7700 (LWP 3238) exited]
[Thread 0x7f219aff5700 (LWP 3240) exited]
[Thread 0x7f219a7f4700 (LWP 3241) exited]
[Thread 0x7f2199ff3700 (LWP 3242) exited]
[Thread 0x7f21997f2700 (LWP 3243) exited]
[Thread 0x7f2198ff1700 (LWP 3244) exited]
[Thread 0x7f21baa03720 (LWP 3213) exited]
[Thread 0x7f21b1e4a700 (LWP 3218) exited]


Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb) bt full
No stack.

Alles anzeigen

Was mach ich noch falsch?

t0mcat · 11. Februar 2016

Hab gerade die cores gefunden... waren umgelenkt nach /var/tmp/core

gdb drauf los gelassen, aber wirklich viel kam dabei auch nicht raus:

Code

Reading symbols from /usr/local/bin/vdr...done.
[New LWP 3703]
[New LWP 3705]
[New LWP 3706]
[New LWP 3676]
[New LWP 3704]
[New LWP 3707]
[New LWP 3708]
[New LWP 3684]
[New LWP 3681]
[New LWP 3687]
[New LWP 3686]
[New LWP 3682]
[New LWP 3690]
[New LWP 3692]
[New LWP 3691]
[New LWP 3685]
[New LWP 3694]
[New LWP 3695]
[New LWP 3693]
[New LWP 3696]
[New LWP 3700]
[New LWP 3698]
[New LWP 3697]
[New LWP 3702]
[New LWP 3699]
[New LWP 3701]


warning: Can't read pathname for load map: Eingabe-/Ausgabefehler.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".


warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffc41876000
Core was generated by `/usr/local/bin/vdr -l 3 -L /usr/lib/vdr/plugins/ ...'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fc751ec6730 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
(gdb) bt full
#0  0x00007fc751ec6730 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
No symbol table info available.
#1  0x00007fc751ec73bc in _Unwind_Backtrace () from /lib/x86_64-linux-gnu/libgcc_s.so.1
No symbol table info available.
#2  0x00007fc751c1c24e in backtrace () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x00007fc751b983af in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00007fc751c1c0e7 in __fortify_fail () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#5  0x00007fc751c1c0b0 in __stack_chk_fail () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#6  0x00007fc74fb1d085 in cxxtools::Utf8Codec::decode(char const*, unsigned int) () from /usr/lib/libcxxtools.so.8
No symbol table info available.
#7  0x0000006900000065 in ?? ()
No symbol table info available.
#8  0x0000006d0000006e in ?? ()
No symbol table info available.
#9  0x0000006c00000061 in ?? ()
No symbol table info available.
#10 0x0000007500000020 in ?? ()
No symbol table info available.
#11 0x000000720000006d in ?? ()
No symbol table info available.
#12 0x0000006e00000075 in ?? ()
No symbol table info available.
#13 0x0000006500000064 in ?? ()
No symbol table info available.
#14 0x000000200000006e in ?? ()
No symbol table info available.
#15 0x0000006900000077 in ?? ()
No symbol table info available.
#16 0x0000006c0000006c in ?? ()
No symbol table info available.
#17 0x0000000a0000002e in ?? ()
No symbol table info available.
#18 0x0000007200000050 in ?? ()
No symbol table info available.
#19 0x000000640000006f in ?? ()
No symbol table info available.
#20 0x0000007a00000075 in ?? ()
No symbol table info available.
#21 0x0000006500000069 in ?? ()
No symbol table info available.
#22 0x0000007400000072 in ?? ()
No symbol table info available.
#23 0x0000006900000020 in ?? ()
No symbol table info available.
#24 0x000000200000006e in ?? ()
No symbol table info available.
#25 0x0000004400000048 in ?? ()
No symbol table info available.
#26 0x0000006100000072 in ?? ()
No symbol table info available.
#27 0x0000007300000074 in ?? ()
No symbol table info available.
#28 0x0000006f00000076 in ?? ()
No symbol table info available.
#29 0x0000007300000072 in ?? ()
No symbol table info available.
#30 0x0000007400000069 in ?? ()
No symbol table info available.
#31 0x000000650000007a in ?? ()
No symbol table info available.

Alles anzeigen

seahawk1986 · 11. Februar 2016

Sieht für mich trotz fehlender Debug-Symbole nach dem bekannten Unicode-Problem aus - vgl. Restfulapi-Plugin und ein paar Posts vorher. Am einfachsten wäre der Gegentest mit der aktuellen Version der Bibliotheken.

t0mcat · 11. Februar 2016

Jups, scheint so, hab die betr. Zeile auch gerade gesehen...

Das mit dem aktualisieren ist so ne sache.. auf der Kiste läuft neben dem VDR noch einiges mehr und ist ne Distri auf Debian Wheezy Basis... da würde ja auch die komplette libc upgedatet werden müssen... ob das gut geht...

t0mcat · 11. Februar 2016

Vielen Dank fürs Schubsen hier hin.

Habe gerade - wie dort angegeben - die Orignalquellen der cxxtools-2.1.1 gepatcht, ein neues .deb gebaut und installiert. Ein erster Test mit einem recording im video.00 Verzeichnis hat schon mal geklappt, kein SegFault mehr...

seahawk1986 · 11. Februar 2016

Zitat von t0mcat

da würde ja auch die komplette libc upgedatet werden müssen

Eigentlich nur cxxtools, tntnet und die davon abhängigen Pakete - also vermutlich live und restfulapi. IIRC hatte hier schon mal jemand gepostet, dass er den Debian Paketmaintainer gefragt hat, ob er das Paket für wheezy aktualisieren würde, aber der wollte nicht.

t0mcat · 11. Februar 2016

Zitat von seahawk1986

Eigentlich nur cxxtools, tntnet und die davon abhängigen Pakete - also vermutlich live und restfulapi. IIRC hatte hier schon mal jemand gepostet, dass er den Debian Paketmaintainer gefragt hat, ob er das Paket für wheezy aktualisieren würde, aber der wollte nicht.

Wenn ich mir das hier so ansehe, sind unter anderen auch die libc zu aktualisieren... die Versionen der abhängigen Pakete sind in Wheezy definitiv kleiner, als dort gefordert.

However, ist dank dem kleinen Patch der 2.1.1er Version der cxxtools ja zum Glück nicht erforderlich, funktioniert damit jetzt alles bestens.

restfulapi: SIGSEGV, Segmentation fault

Jetzt mitmachen!

Teilen