[0.6] gdb und backtrace

ofenheizer · 19. Januar 2016

Servus,

ich benutze noch die 0.6-Installation aus dem Ubuntu-Image mit der preseed-Datei.
Da ich sporadisch segfaults habe, die von epg2vdr (aus dem http-branch) verursacht werden, wollte ich das mal debugggen.
Lt. Handbuch für die 0.6 braucht man nur vdr-dbg zu installieren. Lt. horchi wird epg2vdr schon mit Debug-Symbolen gebaut, wenn man es per Hand macht.

Nun hatte ich heute morgen auch zwei core-Dateien, aber einen segfault zu den beiden Zeitpunkten gab es nicht im log.

Jetzt wollte ich einen Backtrace erzeugen.

Code

gdb vdr-dbg core.1273

Liefert folgende Ausgabe:

Code

GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
vdr-dbg: Datei oder Verzeichnis nicht gefunden.
[New LWP 1273]
[New LWP 1791]
[New LWP 12827]
Core was generated by `/usr/bin/vdr'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f47d78b2cc9 in ?? ()
(gdb)

Alles anzeigen

Hier fällt mir schon auf, dass dort steht "vdr-dbg: Datei oder Verzeichnis nicht gefunden.".
Ein bt full liefert dann nur noch das:

Code

#0  0x00007f47d78b2cc9 in ?? ()
No symbol table info available.
#1  0x00007f47d78b60d8 in ?? ()
No symbol table info available.
#2  0x0000000000000020 in ?? ()
No symbol table info available.
#3  0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)

Jemand eine Idee? Beide cores wurden erzeugt, als sich der VDR ausgeschaltet hat. Im syslog ist aber kein Fehler zu finden.

Markus

mini73 · 19. Januar 2016

Code

gdb vdr core.1273

Lars.

ofenheizer · 19. Januar 2016

Oh danke Lars.
Hatte den Aufruf noch aus der 0.5er-Doku genommen.
Nun sieht es besser aus. Könnt ihr damit etwas anfangen?

Python

root@VDR:/var/log/vdr# gdb vdr core.1273
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vdr...Reading symbols from /usr/lib/debug/.build-id/86/22e2775aeebfe10a751475ee914dc630439107.debug...done.
done.
[New LWP 1273]
[New LWP 1791]
[New LWP 12827]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/vdr'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f47d78b2cc9 in raise () from /lib/x86_64-linux-gnu/libc.so.6
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
(gdb) bt full
#0  0x00007f47d78b2cc9 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007f47d78b60d8 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x00007f47d78ef394 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x00007f47d78fac12 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00007f47d78fb56d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#5  0x00000000005174d5 in cListBase::Clear (this=0x7ed3c0 <CaDescriptorHandler>) at tools.c:2091
        object = 0x7f4778003930
#6  0x00007f47d78b8259 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#7  0x00007f47d78b82a5 in exit () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#8  0x00007f47d789decc in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#9  0x00000000004723b4 in _start ()
No symbol table info available.
(gdb)

Alles anzeigen

Der zweite ist etwas anders.

Python

root@VDR:/var/log/vdr# gdb vdr core.1259
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vdr...Reading symbols from /usr/lib/debug/.build-id/86/22e2775aeebfe10a751475ee914dc630439107.debug...done.
done.
[New LWP 1259]
[New LWP 1838]
[New LWP 3356]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/vdr'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f6b91490cc9 in raise () from /lib/x86_64-linux-gnu/libc.so.6
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
(gdb) bt full
#0  0x00007f6b91490cc9 in raise () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x00007f6b914940d8 in abort () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#2  0x00007f6b914cd394 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#3  0x00007f6b914d8c12 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#4  0x00007f6b914d956d in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#5  0x00000000005174d5 in cListBase::Clear (this=0x1843b60) at tools.c:2091
        object = 0x2518cf0
#6  0x00000000004a2797 in ~cList (this=0x1843b60, __in_chrg=<optimized out>) at tools.h:489
No locals.
#7  ~cScanList (this=0x1843b60, __in_chrg=<optimized out>) at eitscan.c:46
No locals.
#8  cScanList::~cScanList (this=0x1843b60, __in_chrg=<optimized out>) at eitscan.c:46
No locals.
#9  0x00000000004a2083 in cEITScanner::~cEITScanner (this=0x796220 <EITScanner>, __in_chrg=<optimized out>) at eitscan.c:102
No locals.
#10 0x00007f6b91496259 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#11 0x00007f6b914962a5 in exit () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#12 0x00007f6b9147becc in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#13 0x00000000004723b4 in _start ()
No symbol table info available.
(gdb)

Alles anzeigen

Markus

mini73 · 19. Januar 2016

Da löscht jemand Objekte, die noch in der Liste sind. Und wenn die Liste abgeräumt wird, dann versucht es auch, die Objekte zu löschen.
Man darf Objekte, die man in eine cList<> gepackt hat, nicht selbst löschen. Und wenn doch, dann muss man sie manuell mit "DeleteObject == false" vorher aus der Liste nehmen.

Lars.

ofenheizer · 19. Januar 2016

Und nu? Wie geht es weiter? Wer ist der Übeltäter? Ein Plugin oder der VDR?
Wie gesagt, yavdr-0.6 (auf stable)

Code

root@VDR:/var/log/vdr# vdr --showargs
--record=/usr/lib/vdr/vdr-recordingaction
--user=vdr
--grab=/tmp
--port=6419
--watchdog=0
--shutdown=/usr/lib/vdr/vdr-shutdown.wrapper
--dirnames=,,1
--userdump
--chartab=ISO-8859-9
--lirc
--plugin=channellists
--plugin=dbus2vdr --shutdown-hooks=/usr/share/vdr/shutdown-hooks --shutdown-hooks-wrapper=/usr/share/vdr-plugin-dbus2vdr/shutdown-wrapper
--plugin=devstatus
--plugin=epg2vdr
--plugin=epgsearch -f /usr/bin/svdrpsend
--plugin=extrecmenu
--plugin=femon
--plugin=live --port=8008 --ip=0.0.0.0 --log=INFO --epgimages=/var/cache/vdr/epgimages
--plugin=markad
--plugin=menuorg
--plugin=osdteletext
--plugin=pulsecontrol
--plugin=scraper2vdr -i /var/cache/vdr/epgimages/ -m client
--plugin=skindesigner --epgimages=/var/cache/vdr/epgimages
--plugin=softhddevice -D
--plugin=streamdev-server
--plugin=tvguideng
--plugin=undelete
--plugin=vnsiserver
--plugin=weatherforecast
--plugin=dvba**

Alles anzeigen

mini73 · 19. Januar 2016

Wenn es der vdr wäre, hätten vermutlich wesentlich mehr Leute dieses Problem.
Ich würde auf epg2vdr tippen, weil es im Destruktor des EIT-Scanners passiert.

Lars.

ofenheizer · 19. Januar 2016

OK. Ich lass horchi mal drüberschauen.

Danke Dir.

Markus

ofenheizer · 19. Januar 2016

So. Jörg meint epg2vdr ist es nicht, da er nix mit cList im EIT Scanner macht.
Welches Plugin könnte es denn noch sein? Oder sollte ich einfach mal zu allen die -dbg-Pakete installieren?

mini73 · 19. Januar 2016

Zitat von ofenheizer

Oder sollte ich einfach mal zu allen die -dbg-Pakete installieren?

Das schadet nie.

Lars.

seahawk1986 · 19. Januar 2016

Vielleicht auch noch libc6-dbg

mini73 · 19. Januar 2016

Und sicherstellen, dass dein selbstgebautes Plugin gegen die richtigen vdr-Header gebaut wird.

Lars.

ofenheizer · 19. Januar 2016

Zitat von seahawk1986

Vielleicht auch noch libc6-dbg

Erledigt.

Beim installieren der dbg-Pakete ist mir bei 2 Plugins folgendes aufgefallen

Code

root@VDR:~# apt-get install vdr-plugin-markad-dbg
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:


Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 vdr-plugin-markad-dbg : Hängt ab von: vdr-plugin-avahi4vdr (= 0.1.4.git20140218-4yavdr3~trusty) aber 18-0yavdr2~trusty soll installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Alles anzeigen

Code

root@VDR:~# apt-get install vdr-plugin-tvguideng-dbg
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:


Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 vdr-plugin-tvguideng-dbg : Hängt ab von: vdr-plugin-tvguide (= 0.1.6-3-c341a635-0yavdr4~trusty) soll aber nicht installiert werden
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.

Alles anzeigen

Sollte doch bestimmt nicht so sein, oder?

Markus

ofenheizer · 19. Januar 2016

Zitat von mini73

Und sicherstellen, dass dein selbstgebautes Plugin gegen die richtigen vdr-Header gebaut wird.

Öhm. Was gibt es da besonderes zu beachten?
Selbst gebaut sind nur epg2vdr und scraper2vdr.
Beides mit aus dem git geholt und mit make clean, make all und make install installiert.

Markus

seahawk1986 · 19. Januar 2016

Zitat von ofenheizer

Sollte doch bestimmt nicht so sein, oder?

Nein, da hat etwas in den control-Dateien nicht gepasst - neue Pakete sind unterwegs.

mini73 · 19. Januar 2016

Solange die Pluginsourcen nicht in einem vdr-Sourcetree liegen, sollte es passen.

Lars.

ofenheizer · 20. Januar 2016

Moin.

So, nun ist der BT auch etwas länger, für mich aber weiter unverständlich (nach der Installation der gesamten gdb-Pakete wurde der VDR aber noch nicht neu gestartet, da kommt heute sicherlich noch ein weiterer BT).
Hoffe ihr könnt damit mehr anfangen.

Python

root@VDR:/var/log/vdr# gdb vdr core.1258
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vdr...Reading symbols from /usr/lib/debug/.build-id/86/22e2775aeebfe10a751475ee914dc630439107.debug...done.
done.
[New LWP 1258]
[New LWP 1835]
[New LWP 21188]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/bin/vdr'.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f5d3b3b6cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden.
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19-gdb.py", line 63, in <module>
    from libstdcxx.v6.printers import register_libstdcxx_printers
ImportError: No module named 'libstdcxx'
#0  0x00007f5d3b3b6cc9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
        resultvar = 0
        pid = 1258
        selftid = 1258
#1  0x00007f5d3b3ba0d8 in __GI_abort () at abort.c:89
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x5e011a9d, sa_sigaction = 0x5e011a9d}, sa_mask = {__val = {4404639, 4294967295, 5462599, 140038402279432,
              140038435057664, 22035856, 22035856, 211538560, 0, 0, 5462599, 0, 0, 22035856, 140732249972095, 140728898420736}}, sa_flags = 7943184, sa_restorer = 0x0}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f5d3b3f3394 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0x7f5d3b501b28 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
        ap = {{gp_offset = 40, fp_offset = 0, overflow_arg_area = 0x7ffec7c4a010, reg_save_area = 0x7ffec7c49fa0}}
        fd = 2
        on_2 = <optimized out>
        list = <optimized out>
        nlist = <optimized out>
        cp = <optimized out>
        written = <optimized out>
#3  0x00007f5d3b3fec12 in malloc_printerr (ptr=0x1612680, str=0x7f5d3b4fdbfc "corrupted double-linked list", action=1) at malloc.c:4996
        buf = "0000000001612680"
        cp = <optimized out>
#4  malloc_consolidate (av=av@entry=0x7f5d3b73e760 <main_arena>) at malloc.c:4157
        fb = <optimized out>
        maxfb = 0x7f5d3b73e7b0 <main_arena+80>
        p = 0x1612680
        nextp = 0x14f66f0
        unsorted_bin = 0x7f5d3b73e7b8 <main_arena+88>
        first_unsorted = <optimized out>
        nextchunk = 0x1612800
        size = 384
        nextsize = 48
        prevsize = <optimized out>
        nextinuse = <optimized out>
        bck = <optimized out>
        fwd = <optimized out>
        __func__ = "malloc_consolidate"
#5  0x00007f5d3b3ff56d in _int_free (av=0x7f5d3b73e760 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:4057
        size = 8181408
        fb = <optimized out>
        nextchunk = 0x4eebe50
        nextsize = 8181264
        nextinuse = <optimized out>
        prevsize = <optimized out>
        bck = <optimized out>
        fwd = <optimized out>
        errstr = 0x0
        locked = <optimized out>
#6  0x00000000005174d5 in cListBase::Clear (this=0x7ed3c0 <CaDescriptorHandler>) at tools.c:2091
        object = 0x7f5ce4001740
#7  0x00007f5d3b3bc259 in __run_exit_handlers (status=0, listp=0x7f5d3b73e6c8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
        atfct = <optimized out>
        onfct = <optimized out>
        cxafct = <optimized out>
        f = <optimized out>
#8  0x00007f5d3b3bc2a5 in __GI_exit (status=<optimized out>) at exit.c:104
No locals.
#9  0x00007f5d3b3a1ecc in __libc_start_main (main=0x46e2d0 <main(int, char**)>, argc=1, argv=0x7ffec7c4a288, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7ffec7c4a278) at libc-start.c:321
        result = <optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 4564998272453021389, 4662155, 140732249973376, 0, 0, -4564488144749752627, -4476481503686062387},
              mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x52fcd0 <__libc_csu_init>, 0x7ffec7c4a288}, data = {prev = 0x0, cleanup = 0x0, canceltype = 5438672}}}
        not_first_call = <optimized out>
#10 0x00000000004723b4 in _start ()
No symbol table info available.

Alles anzeigen

Markus

mini73 · 20. Januar 2016

Passiert das beim Beenden des vdr oder mitten im Betrieb?

Diesmal ist es die Liste der CA-Descriptors, die da beim Aufräumen ein Problem hat.

Lars.

ofenheizer · 20. Januar 2016

Immer beim Beenden.

mini73 · 20. Januar 2016

Werden vorher noch alle conf-Dateien (channels, setup, timer usw.) gespeichert?
Sowas hab ich früher auch ab und zu mal beobachtet, da es aber quasi so spät, schon fast nach dem Beenden passiert ist (und in letzter Zeit gar nicht mehr), und es sehr schwer zu Debuggen ist und auch keinerlei Konsequenzen für mich hatte, hab ich es ad acta gelegt.

Passiert es, wenn beim Beenden ein verschlüsselter Kanal empfangen wird? Passiert es auch, wenn ein freier Kanal empfangen wird?
Passiert es ohne das Plugin?

Lars.

ofenheizer · 20. Januar 2016

So viele Fragen
Zu den conf-Dateien ... ich denke schon, dass die gespeichert werden, konnte jedenfalls nichts ungewöhnliches feststellen.
Ich schaue beim nächsten mal mit dem Zeitstempel des coredumps im syslog nach, wie spät es passiert.

Gestern abend, beim Ausschalten lief der VDR auf einem freien Kanal. Aber ich werde es auch gerne mal ohne das Plugin probieren.

Markus

[0.6] gdb und backtrace

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema