[vdr-1.7.41] * glibc detected * /opt/vdr-1.7.41/bin/vdr: corrupted double-linked list: 0x0000000000c4b400 ***

mhanu · 24. März 2013

Beim Beenden des VDRs über "Menü Einstellungen -> Neustart" bekomme ich diese Meldung. Der vdr Prozess läuft nach der Meldung weiter ohne aber auf Eingaben zu reagieren.

kls · 24. März 2013

Zitat von mhanu

Beim Beenden des VDRs über "Menü Einstellungen -> Neustart" bekomme ich diese Meldung. Der vdr Prozess läuft nach der Meldung weiter ohne aber auf Eingaben zu reagieren.

Tritt das auch ohne irgendwelche Patches und Plugins (bis auf das für den Output erforderliche) auf?

Klaus

mhanu · 24. März 2013

Ich hab gerade noch einmal komplett (auch alle Plugins) neu kompiliert. Nun tritt das Problem nicht mehr auf.

fnu · 31. März 2013

kls

Ich häng mich hier mal an, bin etwas ratlos. Hab in unserem Paket nur den 1.7.42er Code gegen den 2.0.0er ausgetauscht, der Rest blieb gleich und bekomme beim "vdr -V" diese Ausgabe:

Code

*** glibc detected *** vdr: double free or corruption (!prev): 0x00000000019fffd0 ***======= Backtrace: =========/lib/libc.so.6(+0x78bb6)[0x7fd3b0f68bb6]/lib/libc.so.6(cfree+0x73)[0x7fd3b0f6f483]vdr(_ZN7cThreadD2Ev+0x26)[0x532b36]vdr(_ZN11cRecordingsD1Ev+0x45)[0x4f0725]/lib/libc.so.6(exit+0xe2)[0x7fd3b0f29312]/lib/libc.so.6(__libc_start_main+0x104)[0x7fd3b0f0ec54]vdr[0x46dc99]======= Memory map: ========00400000-0059b000 r-xp 00000000 08:01 152140                             /usr/bin/vdr0079a000-007ac000 r--p 0019a000 08:01 152140                             /usr/bin/vdr007ac000-007ae000 rw-p 001ac000 08:01 152140                             /usr/bin/vdr007ae000-0080f000 rw-p 00000000 00:00 0019c4000-01a69000 rw-p 00000000 00:00 0                                  [heap]7fd3a8000000-7fd3a8021000 rw-p 00000000 00:00 07fd3a8021000-7fd3ac000000 ---p 00000000 00:00 07fd3ac4db000-7fd3ac4e7000 r-xp 00000000 08:01 163510                     /lib/libnss_files-2.11.1.so...7fd3b2931000-7fd3b2951000 r-xp 00000000 08:01 163502                     /lib/ld-2.11.1.so7fd3b29d1000-7fd3b2a10000 r--p 00000000 08:01 135326                     /usr/lib/locale/de_DE.utf8/LC_CTYPE7fd3b2a10000-7fd3b2b2e000 r--p 00000000 08:01 146595                     /usr/lib/locale/de_DE.utf8/LC_COLLATE7fd3b2b2e000-7fd3b2b36000 rw-p 00000000 00:00 07fd3b2b3c000-7fd3b2b3d000 rw-p 00000000 00:00 07fd3b2b3d000-7fd3b2b3e000 r--p 00000000 08:01 135327                     /usr/lib/locale/de_DE.utf8/LC_NUMERIC7fd3b2b3e000-7fd3b2b3f000 r--p 00000000 08:01 146594                     /usr/lib/locale/de_DE.utf8/LC_TIME7fd3b2b3f000-7fd3b2b40000 r--p 00000000 08:01 146597                     /usr/lib/locale/de_DE.utf8/LC_MONETARY7fd3b2b40000-7fd3b2b41000 r--p 00000000 08:01 141993                     /usr/lib/locale/de_DE.utf8/LC_MESSAGES/SYS_LC_MESSAGES7fd3b2b41000-7fd3b2b42000 r--p 00000000 08:01 141994                     /usr/lib/locale/de_DE.utf8/LC_PAPER7fd3b2b42000-7fd3b2b43000 r--p 00000000 08:01 146598                     /usr/lib/locale/de_DE.utf8/LC_NAME7fd3b2b43000-7fd3b2b44000 r--p 00000000 08:01 146599                     /usr/lib/locale/de_DE.utf8/LC_ADDRESS7fd3b2b44000-7fd3b2b45000 r--p 00000000 08:01 146600                     /usr/lib/locale/de_DE.utf8/LC_TELEPHONE7fd3b2b45000-7fd3b2b46000 r--p 00000000 08:01 141998                     /usr/lib/locale/de_DE.utf8/LC_MEASUREMENT7fd3b2b46000-7fd3b2b4d000 r--s 00000000 08:01 163468                     /usr/lib/gconv/gconv-modules.cache7fd3b2b4d000-7fd3b2b4e000 r--p 00000000 08:01 146601                     /usr/lib/locale/de_DE.utf8/LC_IDENTIFICATION7fd3b2b4e000-7fd3b2b50000 rw-p 00000000 00:00 07fd3b2b50000-7fd3b2b51000 r--p 0001f000 08:01 163502                     /lib/ld-2.11.1.so7fd3b2b51000-7fd3b2b52000 rw-p 00020000 08:01 163502                     /lib/ld-2.11.1.so7fd3b2b52000-7fd3b2b53000 rw-p 00000000 00:00 07fff5182a000-7fff5183f000 rw-p 00000000 00:00 0                          [stack]7fff518bd000-7fff518be000 r-xp 00000000 00:00 0                          [vdso]ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]Speicherzugriffsfehler

Der Fehler wird von keinem Plugin verursacht, alle geprüft, sondern vom VDR selbst und war bei 1.7.42 kein Problem. Hat sich hier noch was entscheidendes zu 1.7.42 geändert, was man wissen/beachten müßte?

Regards
fnu

johns · 31. März 2013

Ich würde zwar auf ein Plugin tippen, aber lass mal mit valgrind laufen.

Johns

fnu · 31. März 2013

Zitat von johns

Ich würde zwar auf ein Plugin tippen, aber lass mal mit valgrind laufen.

Sonst würde ich Dir Recht geben, aber ich habe alle schon geprüft und der VDR produziert das Ding auch solo hier ... allerdings nicht Patch-frei, aber die selben waren mit 1.7.42 kein Problem ... daher die Frage was sich noch geändert hat zu 1.7.42 ...

Wenn ich das richtig sehe, gab es nur noch in der timers.c eine Code-Änderung ...

seahawk1986 · 31. März 2013

Nur mal um das weiter einzugrenzen:
Betrifft das nur lucid oder auch precise (um den dvbapi-wrapper auszuschließen)?
Ich kann das Verhalten unter Arch Linux mit diesen Patches und dem VDR 2.0.0 nicht nachvollziehen.
Patchstand ist der gleiche wie für die 1.7.42 hier:
https://github.com/seahawk1986…b/yaarch/vdr/PKGBUILD#L67

fnu · 31. März 2013

Zitat von seahawk1986

Betrifft das nur lucid oder auch precise (um den dvbapi-wrapper auszuschließen)?

s2apiwrapper war in der gleichen version bei 1.7.42 für Lucid mit drin, die fehlerfrei funktionierte, gibt also nix auszuschliessen ... aber Udo war inzwischen fleissig, mal sehen ...

kls · 31. März 2013

Zitat von fnu

... daher die Frage was sich noch geändert hat zu 1.7.42 ...
Wenn ich das richtig sehe, gab es nur noch in der timers.c eine Code-Änderung ...

Die einzige echte Code-Änderung ist die in timers.c (alles andere sind nur Versionsnummern).
Ich kann mir nicht vorstellen, daß das ein solches Problem hervorrufen sollte.
Bau doch mal die Änderung in deine 1.7.42-er Version ein und probier, ob damit der Fehler dort auch auftritt.
Oder umgekehrt, bau die Änderung in der 2.0.0 wieder zurück und schau, ob der Fehler weg ist.

Klaus

fnu · 1. April 2013

So, VDR Paket neu gebaut mit aktualisiertem s2apiwrapper 0.10 von urig, Fehler tritt immer noch auf, aber interessanterweise nimmer mit:

Code

vdr -V -L /tmpvdr (2.0.0/2.0.0) - The Video Disk Recorder

Kein segfault, cool. Nun jedes Plugin einzeln mit "vdr -V -Pplugin", auch alles gut, kein segfault, hmm.

Das Muster muß wohl etwas aufwändiger gestaltet werden:

Code

vdr -V -P plugin1 -Pplugin2 -Pplugin3 .... -PpluginN

Wie erwartet, segfault. Also dann ein Plugin nachdem anderen rausnehmen, erster Kandidat, "vdr-plugin-undelete", eben alleine probiert:

Code

vdr -V -Pundeletevdr (2.0.0/2.0.0) - The Video Disk Recorderundelete (0.0.6) - undelete for recordings

Aha, fast schon erwartungsgemäß einzeln kein segfault, war ja schon geprüft. Also undelete wieder rein in die Zeile und weitere einzelne Plugins rausgenommen, nächster Kandidat "vdr-plugin-skinelchi":

Code

vdr -V -Pskinelchivdr (2.0.0/2.0.0) - The Video Disk Recorderskinelchi (0.2.7) - Elchi skin

wieder erwartungsgemäß einzeln kein segfault. Aber in der Kombination:

Code

vdr -V -Pskinelchi -Pundeletevdr (2.0.0/2.0.0) - The Video Disk Recorderskinelchi (0.2.7) - Elchi skinundelete (0.0.6) - undelete for recordingsSpeicherzugriffsfehler

Da soll man also drauf kommen ... klar, ist doch ganz einfach und logisch ...

Nun denn jetzt muß der Normalsterbliche nur noch rausfinden, warum skinelchi und undelete in der Kombination bei dieser Abfrage Probleme machen bzw. bei 1.7.42 nicht, wenn auch mit ganz leicht anderen Randbedingungen ...

Regards
fnu

[vdr-1.7.41] * glibc detected * /opt/vdr-1.7.41/bin/vdr: corrupted double-linked list: 0x0000000000c4b400 ***

Jetzt mitmachen!

Teilen