Vielen, vielen Dank Jörg!
Funktioniert bei mir mit der neuen Version nun auch.
Viele Grüße,
Chriss
Vielen, vielen Dank Jörg!
Funktioniert bei mir mit der neuen Version nun auch.
Viele Grüße,
Chriss
Hallo ciax,
willkommen Leidensgenosse. Hab' mit der gleichen Unart zu kämpfen, jedoch aufgegeben und zurückgerollt, s. hier:
Viele Grüß,
Chriss
Was hast du denn noch an Plugins bzw. an Patchen?
Bewusst nur den einen Patch - bei 2.6.6 muss ich genauer hinschauen.
Bei VDR-2.7.3 definitiv nur den für libcap fürs statusleds-plugin, hatte die VDR-Version direkt via git ausgecheckt und den Patch angewendet.
Habe es als Anlass genommen, meine Signatur auf Stand zu bringen ...
Plugins: epg2vdr, lcdproc, markad, skindesigner, softhddevice, statusleds, streamdev-server, svdrpservice, vnsiserver
Ab welcher vdr Version passiert das bei dir (bisect zwischen 2.6.6 und 2.7.3 = 3 Tests)?
Sehr gute Idee, bin dran, wird aber etwas dauern.
Sorry, hatte das vergessen zu schreiben ...
Ging es denn mit vdr-2.6.6?
Jupp, daher bin ich ja so überrascht.
Wenn dies andere mit einem aktuellen und gepatchten VDR nicht haben, verbuche ich es einfach als eine Merkwürdigkeit meines Systems - und behalte es im Auge bei künftigen Versionen.
Danke jrie!
Interessant wird's leider nun umso mehr. In Ubuntu ist die v2.66 von libcap schon seit 23.10 enthalten (wenn die Infos von cap_from_text stimmen), davor war's 2.44. Bin auch die Änderungen zwischen 2.63 und 2.66 einzeln durchgegangen und habe dabei für meine Augen nichts auch nur annähernd Verdächtiges gefunden.
Musste mein System auf kUbuntu 24.04 zurückrollen (Backup der Platte von vorher eingespielt), weil Ubuntu in 24.10 Wayland als default eingestellt hat.
Da softhddevice kein Fenster mit Wayland geöffnet bekommt ... und ich es ums Verrecken nicht hinbekommen habe, X11 wieder zu reaktivieren, ohne mich dazu jedes Mal manuell anmelden und dabei X11 auswählen zu müssen, habe ich die Rolle rückwärts gemacht.
Trotzdem habe ich dann von vdr-2.6.6 auf vdr-2.7.3 aktualisiert (ich compiliere immer alles rund um den VDR selber) und da ist das Verhalten haargenau gleich.
Mit Patch kommt: cap_from_text failed: Invalid argument, ohne Patch: natürlich kein blinkendes LED; weshalb ich momentan noch "meine" Version von statusleds weiterbenutze, die den blinkd nutzt.
Bin also erst einmal noch ratloser als vorher, aber ggf. hilft dies dem einen oder anderen Mitleser, sich ein Update auf (k)Ubuntu in ähnlichem Szenario wie meinem, reiflich zu überlegen oder für sich schneller Ursachen eingrenzen zu können.
Viele Grüße,
Chriss
Hallo zusammen,
habe heute von kUbuntu 24.04 auf 24.10 aktualisiert, den VDR (2.7.3) und Plugins neu kompiliert und nun logged das statusleds-plugin:
2024-11-14T17:19:33.008777+01:00 HTPC vdr[92982]: vdr: cap_from_text failed: Invalid argument
2024-11-14T17:19:33.009450+01:00 HTPC systemd[1]: vdr.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
2024-11-14T17:19:33.009506+01:00 HTPC systemd[1]: vdr.service: Failed with result 'exit-code'.
wenn der VDR mit dem folgenden Patch versehen wurde (aus "patch_for_vdr.diff" aus dem neuen Plugin Sourcecode:
Wenn ich dies entferne, startet der VDR normal, aber kann "natürlich" die Keyboard LED bei einer Aufnahme nicht blinken lassen.
VDR logged dann beim Start:
2024-11-14T18:20:47.695110+01:00 HTPC vdr: [103227] Status LED's: Thread started (pid=103204)
2024-11-14T18:20:47.695143+01:00 HTPC vdr: [103227] ERROR: Status LED's: Can't open console /dev/tty
2024-11-14T18:20:47.695165+01:00 HTPC vdr: [103227] Status LED's: Thread ended (pid=103204)
Habe ich auch hier gemeldet, vielleicht kennt jemand ja eine Lösung oder hat eine Idee dazu ...
Viele Grüße,
Chriss
aber TVSP geht nur 1 Woche
Der Vollständigkeit halber: Ist bei mir auch bis 7.8. vorhanden.
Ok, also irgendwas beim Update des EPG ist definitiv kaputt.
Wenn man alles von Grund auf neu aufbauen lässt, ist vor und auch nach dem ersten Schreiben der Daten ins EPG die EPGD-Datenbank völlig in Ordnung, im EPG des VDR dagegen ist vor dem ersten Schreiben noch alles in Ordnung, danach sind alle Sendungen doppelt vorhanden (einmal mit, einmal ohne Daten von TVSP/TVM).
Dreimal getestet - dreimal dasselbe Ergebnis.
Was nun?
Hast du mal bei horchi angeklopft? Vielleicht hat er eine spontane Idee.
Lt. der Tabelle vdrs gab es auch noch keinen merge - falls der Eintrag da was zu bedeuten hat.
Dafür habe ich jetzt jeden Eintrag bereits dreimal - jeder davon sieht etwas anders aus 8-(
Kann es sein, dass der Merge kaputt ist?
Hast du ggfs. mehrere epgd-Instanzen in der Tabelle vdrs stehen, die auf unterschiedlichen Interfaces horchen und somit zu unterschiedlichen Timestamps den Merge machen sollten? Das Problem hatte ich letzte Woche, bis ich mal gecheckt hatte, dass "lastmerge" bei dem "richtigen" vdr-Eintrag NULL gewesen war. Wie auch immer es dazu gekommen war.
allerdings verliere ich dabei wieder mal meine 100 Searchtimer
Ich hoffe, du exportierst die dir mit SQL-Mitteln vorher und importierst sie danach wieder.
Sonst wirst' ja rammdösig
Hast du was an der channelmap.conf geändert ?
Irgendwie sieht es fast so aus, als würde EPGD die VDR-Events nicht mit denen aus TVM/TVSP matchen können, weil auch keinerlei Daten aus TVM/TVSP im EPG zu sehen sind.
Ich bin echt ratlos 8-<
Wie sehen denn die Einträge (bzw. der Eintrag) in der channelmap.conf aus (jetzt mal nur konkret für den Eureka-Fall?). Vielleicht ist ja schon dort irgendetwas erkennbar?
Habe dies aber auch öfters - wenn ich mich nicht irre, nur bei Sendern, die gemerged werden sollen, also wo VDR-EPG und das Externe eigentlich zusammenkommen sollen ...
Hallo nobanzai,
wenn ich das richtig interpretiere, was epgd mit meinen Timern so tut, wenn es solche Meldungen liefert, dann ist es so:
Es gab mal das Event (also einen EPG-Eintrag) dafür, es wurde ein Timer angelegt.
Jetzt ist das Event nicht mehr vorhanden Event (62899) '' of timer (frag' mich nicht, wieso) und dann entfernt epgd auch den Timer dazu.
Wenn ich das falsch interpretiere, möge man mich bitte korrigieren.
Du kannst ja mal nach dem Rockpalast suchen, den er hier eigentlich mal gemeint hat. Dürfte dann nichts zurückkommen, wenn ich mir das richtig zusammenreime.
Viele Grüße,
Chriss
Hi Hopsi,
hast du auch schonmal versucht, epghttpd so zu bauen, wie horchi hier in Beitrag #23 segfault von epghttpd beim Speichern von Timern vorgeschlagen hat?
Denk' dabei dann direkt hier dran :
Jup (muss ich eigentlich -fno-stack-protector -O0 aus dem ifdef DEBUG Block auch noch entfernen, weil sich sonst das -O2 und -O0 bzw. die unterschiedlichen stack-protection Optionen beißen?):
Viele Grüße,
Chriss
beim make solltest du dann sehen das die Optionen verwendet werden
Jup (muss ich eigentlich -fno-stack-protector -O0 aus dem ifdef DEBUG Block auch noch entfernen, weil sich sonst das -O2 und -O0 bzw. die unterschiedlichen stack-protection Optionen beißen?):
...
Compile main ..
g++ -c -I/usr/include/mariadb -I/usr/include/mariadb/mysql -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -D_GLIBCXX_ASSERTIONS -fstack-clash-protection -fstack-protector-strong -Wl,-z,nodlopen -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -fcf-protection=full -Wtrampolines -O2 -I/usr/include/python3.12 -I/usr/include/python3.12 -ggdb -fno-stack-protector -O0 -std=c++17 -D__STDC_FORMAT_MACROS -fPIC -Wall -Wreturn-type -Wformat -Wextra -Wparentheses -pedantic -Werror=format-security -Wunused-variable -Wunused-label -Wunused-value -Wunused-function -Wunused-local-typedefs -Wno-unused-parameter -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -DBINDEST='"/usr/local/bin"' -DTARGET='"epgd"' -DLOG_PREFIX='""' -DPLGDIR='"/usr/local/lib/epgd/plugins"' -DUSEUUID -DUSEMD5 -DUSELIBXML -DUSELIBARCHIVE -DUSEJSON -DUSEGUNZIP -DSYSDWDIFO -DUSESYSD -I/usr/include/libxml2 -I/usr/include/libxml2 -I/usr/include/python3.12 -I/usr/include/python3.12 -DGIT_REV='"544018b"' -o main.o main.c
...
aber wie kommt man nun dem Problem besser auf die Spur?
Sieht immer noch gleich aus für meine Augen:
coredumpctl debug
PID: 18962 (epghttpd)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Tue 2024-06-11 19:10:14 CEST (6s ago)
Command Line: /usr/local/bin/epghttpd -c /etc/epgd
Executable: /usr/local/bin/epghttpd
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-c016959c7428465991e1e247bec66be9.scope
Unit: user@1000.service
User Unit: app-org.kde.konsole-c016959c7428465991e1e247bec66be9.scope
Slice: user-1000.slice
Owner UID: 1000 (chriss)
Boot ID: 17a00bab39494b16b49a9b641e52cf0a
Machine ID: 3e19bda874a04977b50b2196499bd616
Hostname: HTPC
Storage: /var/lib/systemd/coredump/core.epghttpd.0.17a00bab39494b16b49a9b641e52cf0a.18962.1718125814000000.zst (present)
Size on Disk: 1.3M
Message: Process 18962 (epghttpd) of user 0 dumped core.
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2build1.amd64
Module libsystemd.so.0 from deb systemd-255.4-1ubuntu8.1.amd64
Module libarchive.so.13 from deb libarchive-3.7.2-2ubuntu0.1.amd64
Stack trace of thread 18963:
#0 0x0000759e488f78d5 _PyThreadState_HasStackSpace (libpython3.12.so.1.0 + 0x2f78d5)
#1 0x0000759e4889c936 _PyEvalFramePushAndInit (libpython3.12.so.1.0 + 0x29c936)
#2 0x0000759e4889d356 _PyEval_Vector (libpython3.12.so.1.0 + 0x29d356)
#3 0x0000759e48784b76 _PyObject_VectorcallTstate (libpython3.12.so.1.0 + 0x184b76)
#4 0x000059164ec8454e _ZN6Python7executeEP8cDbTableiPKc (epghttpd + 0xfc54e)
#5 0x000059164ec0d4ec _ZN9cEpgHttpd13storeTimerJobEP6json_tS1_ (epghttpd + 0x854ec)
#6 0x000059164ec287e1 _ZN9cEpgHttpd15performPostDataEPKcP12MemoryStruct (epghttpd + 0xa07e1)
#7 0x000059164ec29107 _ZN9cEpgHttpd10dispatcherEPvP14MHD_ConnectionPKcS4_S4_S4_PmPS0_ (epghttpd + 0xa1107)
#8 0x0000759e48ed972e call_connection_handler (libmicrohttpd.so.12 + 0xb72e)
#9 0x0000759e48edc1e8 MHD_connection_handle_idle (libmicrohttpd.so.12 + 0xe1e8)
#10 0x0000759e48edf5e8 call_handlers (libmicrohttpd.so.12 + 0x115e8)
#11 0x0000759e48ee0c61 MHD_epoll (libmicrohttpd.so.12 + 0x12c61)
#12 0x0000759e48eea035 MHD_polling_thread (libmicrohttpd.so.12 + 0x1c035)
#13 0x0000759e4769ca94 start_thread (libc.so.6 + 0x9ca94)
#14 0x0000759e47729c3c __clone3 (libc.so.6 + 0x129c3c)
Stack trace of thread 18962:
#0 0x0000759e476ecadf __GI___clock_nanosleep (libc.so.6 + 0xecadf)
#1 0x0000759e476f9a27 __GI___nanosleep (libc.so.6 + 0xf9a27)
#2 0x0000759e4770ec63 __sleep (libc.so.6 + 0x10ec63)
#3 0x000059164ec2737f _ZN9cEpgHttpd4loopEv (epghttpd + 0x9f37f)
#4 0x000059164ec2ad52 main (epghttpd + 0xa2d52)
#5 0x0000759e4762a1ca __libc_start_call_main (libc.so.6 + 0x2a1ca)
#6 0x0000759e4762a28b __libc_start_main_impl (libc.so.6 + 0x2a28b)
#7 0x000059164ec0b945 _start (epghttpd + 0x83945)
ELF object binary architecture: AMD x86-64
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 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:
<https://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 /usr/local/bin/epghttpd...
[New LWP 18963]
[New LWP 18962]
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.ubuntu.com>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /lib/x86_64-linux-gnu/libz.so.1
Downloading separate debug info for /lib/x86_64-linux-gnu/libarchive.so.13
[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/local/bin/epghttpd -c /etc/epgd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000759e488f78d5 in _PyThreadState_HasStackSpace (size=28, tstate=0x0) at ../Include/internal/pycore_frame.h:248
248 return tstate->datastack_top != NULL &&
[Current thread is 1 (Thread 0x759e43a006c0 (LWP 18963))]
(gdb) bt
#0 0x0000759e488f78d5 in _PyThreadState_HasStackSpace (size=28, tstate=0x0) at ../Include/internal/pycore_frame.h:248
#1 _PyThreadState_PushFrame (tstate=tstate@entry=0x0, size=28) at ../Python/pystate.c:2972
#2 0x0000759e4889c936 in _PyEvalFramePushAndInit (tstate=0x0, func=0x759e43fda2a0, locals=0x0, args=0x0, argcount=0, kwnames=0x0) at ../Python/ceval.c:1589
#3 0x0000759e4889d356 in _PyEval_Vector (tstate=0x0, func=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=<optimized out>) at ../Python/ceval.c:1677
#4 0x0000759e48784b76 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=0, args=0x0, callable=<function at remote 0x759e43fda2a0>, tstate=0x0) at ../Include/internal/pycore_call.h:92
#5 _PyObject_CallNoArgsTstate (func=<function at remote 0x759e43fda2a0>, tstate=0x0) at ../Include/internal/pycore_call.h:99
#6 PyObject_CallObject (callable=<function at remote 0x759e43fda2a0>, args=0x0) at ../Objects/call.c:469
#7 0x000059164ec8454e in Python::execute (this=0x59164ed6db10, eventsDb=0x59164ee7bc40, namingmode=1, tmplExpression=0x759e3c009be0 "") at python.c:310
#8 0x000059164ec0d4ec in cEpgHttpd::storeTimerJob (this=0x59164ed6cd00, jInData=0x759e3c0093c0, response=0x759e3c0092e0) at webstore.c:309
#9 0x000059164ec287e1 in cEpgHttpd::performPostData (this=0x59164ed6cd00, url=0x759e3c000e05 "/data/save-timer", data=0x759e439fe8e0) at httpd.c:1624
#10 0x000059164ec29107 in cEpgHttpd::dispatcher (cls=0x0, tcp=0x759e3c000b70, url=0x759e3c000e05 "/data/save-timer", method=0x759e3c000e00 "POST", version=0x759e3c000e16 "HTTP/1.1", upload_data=0x0, upload_data_size=0x759e439fecb0,
con_cls=0x759e3c000c28) at httpd.c:1777
#11 0x0000759e48ed972e in call_connection_handler (connection=connection@entry=0x759e3c000b70) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/connection.c:4366
#12 0x0000759e48edc1e8 in MHD_connection_handle_idle (connection=connection@entry=0x759e3c000b70) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/connection.c:7329
#13 0x0000759e48edf5e8 in call_handlers (con=con@entry=0x759e3c000b70, read_ready=<optimized out>, write_ready=<optimized out>, force_close=false) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:1320
#14 0x0000759e48ee0c61 in MHD_epoll (daemon=0x59164f11d290, millisec=<optimized out>) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:5766
#15 0x0000759e48eea035 in MHD_polling_thread (cls=0x59164f11d290) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:6025
#16 0x0000759e4769ca94 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#17 0x0000759e47729c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Display More
Ist übrigens auch immer noch nur der epghttpd inkl. der Änderungen aus https://www.vdr-portal.de/forum/index.php?thread/136271-segfault-von-epghttpd-beim-speichern-von-timern/&pageNo=2
den ich nach dem Bauen an seinen Bestimmungsort kopiert und dann gestartet habe. Der epgd ist "der Alte", der läuft ja und erstellt auch Timer via Autotimer korrekt, selbst mit "Auto" Option ...
Die beiden Optionen sind Neuland für mich.
Meinst du mit FORTIFY, gcc mit passenden Optionen/Flags zu versorgen, wie z.B. hier beschrieben und das Gleiche für Stack Protection?
Merci horchi!
Habe epghttpd nach deiner Vorgabe neu gebaut und die Executable davon benutzt ...
Hat für mich erkennbar nur eine Sache geändert, nämlich, dass die Zeile Initialize python script '/etc/epgd/recording.py' nur einmal kommt:
2024-06-10T18:40:11.659476+02:00 HTPC epghttpd: Set locale to 'de_DE.UTF-8'
2024-06-10T18:40:11.659554+02:00 HTPC epghttpd: detected UTF-8
2024-06-10T18:40:11.659571+02:00 HTPC epghttpd: Read 31 option from /etc/epgd/epgd.conf
2024-06-10T18:40:11.659585+02:00 HTPC epghttpd: Initialize python script '/etc/epgd/recording.py'
2024-06-10T18:40:11.671019+02:00 HTPC epghttpd: Dictionary '/etc/epgd/epg.dat' loaded
2024-06-10T18:40:11.671106+02:00 HTPC epghttpd: Info: Calling mysql_library_init()
2024-06-10T18:40:11.671841+02:00 HTPC epghttpd: Connecting to database at 'localhost:3306'
2024-06-10T18:40:11.671882+02:00 HTPC epghttpd: Calling mysql_init(17790)
2024-06-10T18:40:11.672188+02:00 HTPC epghttpd: SQL client character now 'utf8mb3'
2024-06-10T18:40:11.676618+02:00 HTPC epghttpd: Info: Eloquence set to 'Error,Warning,Info,' => 0x0007
2024-06-10T18:40:11.680179+02:00 HTPC epghttpd: Calling mysql_init(17790)
2024-06-10T18:40:11.686289+02:00 HTPC epghttpd: Starting http server ...
2024-06-10T18:40:11.686330+02:00 HTPC epghttpd: Listener at port 8888 established, waiting for connections
2024-06-10T18:40:11.686345+02:00 HTPC epghttpd: Calling sd_notify(READY=1$STATUS=Ready$MAINPID=17790$)
2024-06-10T18:40:11.686361+02:00 HTPC epghttpd: Info: Systemd watchdog not configured, epgd won't be sending keep-alive messages!
Display More
Und dies habe ich bisher noch nicht gesehen, scheint mir aber eine ganz andere Baustelle und somit Zufallsfund zu sein:
2024-06-10T18:40:38.003433+02:00 HTPC epghttpd: webif: TypeError: t.find(...)[0] is undefined$line: 1$column: 100433$error: loadData/<@http:/192.168.0.10:8888/epgd.js?1.3.24:1:100433$i@http://192.168.0.10:8888/common.js?1.3.24:2:27151$fireWith@http://192.168.0.10:8888/common.js?1.3.24:2:27914$z@http://192.168.0.10:8888/common.js?1.3.24:4:12120$send/c/<@http://192.168.0.10:8888/common.js?1.3.24:4:15680$
Hier noch der bt von der gepatchten Version des epghttpd:
#0 0x000073ada68f78d5 in _PyThreadState_HasStackSpace (size=28, tstate=0x0) at ../Include/internal/pycore_frame.h:248
#1 _PyThreadState_PushFrame (tstate=tstate@entry=0x0, size=28) at ../Python/pystate.c:2972
#2 0x000073ada689c936 in _PyEvalFramePushAndInit (tstate=0x0, func=0x73ada1fda340, locals=0x0, args=0x0, argcount=0, kwnames=0x0) at ../Python/ceval.c:1589
#3 0x000073ada689d356 in _PyEval_Vector (tstate=0x0, func=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=<optimized out>) at ../Python/ceval.c:1677
#4 0x000073ada6784b76 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=0, args=0x0, callable=<function at remote 0x73ada1fda340>, tstate=0x0) at ../Include/internal/pycore_call.h:92
#5 _PyObject_CallNoArgsTstate (func=<function at remote 0x73ada1fda340>, tstate=0x0) at ../Include/internal/pycore_call.h:99
#6 PyObject_CallObject (callable=<function at remote 0x73ada1fda340>, args=0x0) at ../Objects/call.c:469
#7 0x000058106c50bbae in Python::execute (this=0x58106e4a4b10, eventsDb=0x58106e5b3a40, namingmode=1, tmplExpression=0x73ad9c0199e0 "") at python.c:310
#8 0x000058106c498c2c in cEpgHttpd::storeTimerJob (this=0x58106e4a3d00, jInData=0x73ad9c008b30, response=0x73ad9c010740) at webstore.c:309
#9 0x000058106c4b2227 in cEpgHttpd::performPostData (this=0x58106e4a3d00, url=0x73ad9c030a35 "/data/save-timer", data=0x73ada19fe8e0) at httpd.c:1624
#10 0x000058106c4b2b4d in cEpgHttpd::dispatcher (cls=0x0, tcp=0x73ad9c019660, url=0x73ad9c030a35 "/data/save-timer", method=0x73ad9c030a30 "POST", version=0x73ad9c030a46 "HTTP/1.1", upload_data=0x0, upload_data_size=0x73ada19fecb0,
con_cls=0x73ad9c019718) at httpd.c:1777
#11 0x000073ada6f7972e in call_connection_handler (connection=connection@entry=0x73ad9c019660) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/connection.c:4366
#12 0x000073ada6f7c1e8 in MHD_connection_handle_idle (connection=connection@entry=0x73ad9c019660) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/connection.c:7329
#13 0x000073ada6f7f5e8 in call_handlers (con=con@entry=0x73ad9c019660, read_ready=<optimized out>, write_ready=<optimized out>, force_close=false) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:1320
#14 0x000073ada6f80c61 in MHD_epoll (daemon=0x58106e85c390, millisec=<optimized out>) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:5766
#15 0x000073ada6f8a035 in MHD_polling_thread (cls=0x58106e85c390) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:6025
#16 0x000073ada569ca94 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#17 0x000073ada5729c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Display More
Bin wieder und weiterhin ratlos.
Hi horchi,
danke vielmals für das mini-How-To. Resultat ist:
$ ./pytst "tvm" "S19.2E-1-1107-17501" 191051494 1
20:57:13,346 Info: Calling mysql_library_init()
20:57:13,346 Calling mysql_init(14130)
20:57:13,347 SQL client character now 'utf8mb3'
20:57:13,347 Event 'Die Simpsons/Angst essen Seele auf' found
20:57:13,347 Initialize python script '/etc/epgd/recording.py'
20:57:13,367 Result of call: Die Simpsons~17x02 - 358. Angst essen Seele auf
20:57:13,367 Info: The recording name calculated by 'recording.py' (with namingmode 1) is 'Die Simpsons~17x02 - 358. Angst essen Seele auf'
20:57:13,370 Info: Released the last usage of mysql_lib, calling mysql_library_end() now
20:57:13,370 Closing mysql connection and calling mysql_thread_end(14130)
Weiß jetzt nur nicht, ob ich das gut oder schlecht finden soll
Viele Grüße,
Chriss
So, heute ließ sich das Repository der debug-Symbole ansprechen und ich habe das einzige Paket, das ansatzweise danach aussieht, installiert:
Der BT sieht nicht anders aus?!
$ coredumpctl debug
PID: 19877 (epghttpd)
UID: 1000 (chriss)
GID: 4 (adm)
Signal: 11 (SEGV)
Timestamp: Thu 2024-06-06 18:41:15 CEST (8s ago)
Command Line: /usr/local/bin/epghttpd -c /etc/epgd
Executable: /usr/local/bin/epghttpd
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole-3a9805d827f0429485f75ee75da25c83.scope
Unit: user@1000.service
User Unit: app-org.kde.konsole-3a9805d827f0429485f75ee75da25c83.scope
Slice: user-1000.slice
Owner UID: 1000 (chriss)
Boot ID: 259bcadfc6a74988b404bd5e3c02dd72
Machine ID: 3e19bda874a04977b50b2196499bd616
Hostname: HTPC
Storage: /var/lib/systemd/coredump/core.epghttpd.1000.259bcadfc6a74988b404bd5e3c02dd72.19877.1717692075000000.zst (present)
Size on Disk: 1.3M
Message: Process 19877 (epghttpd) of user 1000 dumped core.
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2build1.amd64
Module libsystemd.so.0 from deb systemd-255.4-1ubuntu8.1.amd64
Module libarchive.so.13 from deb libarchive-3.7.2-2ubuntu0.1.amd64
Stack trace of thread 19878:
#0 0x00007c25bd4f78d5 _PyThreadState_HasStackSpace (libpython3.12.so.1.0 + 0x2f78d5)
#1 0x00007c25bd49c936 _PyEvalFramePushAndInit (libpython3.12.so.1.0 + 0x29c936)
#2 0x00007c25bd49d356 _PyEval_Vector (libpython3.12.so.1.0 + 0x29d356)
#3 0x00007c25bd384b76 _PyObject_VectorcallTstate (libpython3.12.so.1.0 + 0x184b76)
#4 0x00006068dd746e50 _ZN6Python7executeEP8cDbTableiPKc (epghttpd + 0xf7e50)
#5 0x00006068dd6d3c2c _ZN9cEpgHttpd13storeTimerJobEP6json_tS1_ (epghttpd + 0x84c2c)
#6 0x00006068dd6ed227 _ZN9cEpgHttpd15performPostDataEPKcP12MemoryStruct (epghttpd + 0x9e227)
#7 0x00006068dd6edb4d _ZN9cEpgHttpd10dispatcherEPvP14MHD_ConnectionPKcS4_S4_S4_PmPS0_ (epghttpd + 0x9eb4d)
#8 0x00007c25bdc4f72e call_connection_handler (libmicrohttpd.so.12 + 0xb72e)
#9 0x00007c25bdc521e8 MHD_connection_handle_idle (libmicrohttpd.so.12 + 0xe1e8)
#10 0x00007c25bdc555e8 call_handlers (libmicrohttpd.so.12 + 0x115e8)
#11 0x00007c25bdc56c61 MHD_epoll (libmicrohttpd.so.12 + 0x12c61)
#12 0x00007c25bdc60035 MHD_polling_thread (libmicrohttpd.so.12 + 0x1c035)
#13 0x00007c25bc29ca94 start_thread (libc.so.6 + 0x9ca94)
#14 0x00007c25bc329c3c __clone3 (libc.so.6 + 0x129c3c)
Stack trace of thread 19877:
#0 0x00007c25bc2ecadf __GI___clock_nanosleep (libc.so.6 + 0xecadf)
#1 0x00007c25bc2f9a27 __GI___nanosleep (libc.so.6 + 0xf9a27)
#2 0x00007c25bc30ec63 __sleep (libc.so.6 + 0x10ec63)
#3 0x00006068dd6ebdc5 _ZN9cEpgHttpd4loopEv (epghttpd + 0x9cdc5)
#4 0x00006068dd6ef798 main (epghttpd + 0xa0798)
#5 0x00007c25bc22a1ca __libc_start_call_main (libc.so.6 + 0x2a1ca)
#6 0x00007c25bc22a28b __libc_start_main_impl (libc.so.6 + 0x2a28b)
#7 0x00006068dd6d2085 _start (epghttpd + 0x83085)
ELF object binary architecture: AMD x86-64
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
Copyright (C) 2024 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:
<https://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 /usr/local/bin/epghttpd...
[New LWP 19878]
[New LWP 19877]
This GDB supports auto-downloading debuginfo from the following URLs:
<https://debuginfod.ubuntu.com>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /lib/x86_64-linux-gnu/libarchive.so.13
[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/local/bin/epghttpd -c /etc/epgd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007c25bd4f78d5 in _PyThreadState_HasStackSpace (size=28, tstate=0x0) at ../Include/internal/pycore_frame.h:248
248 return tstate->datastack_top != NULL &&
[Current thread is 1 (Thread 0x7c25b88006c0 (LWP 19878))]
(gdb) bt
#0 0x00007c25bd4f78d5 in _PyThreadState_HasStackSpace (size=28, tstate=0x0) at ../Include/internal/pycore_frame.h:248
#1 _PyThreadState_PushFrame (tstate=tstate@entry=0x0, size=28) at ../Python/pystate.c:2972
#2 0x00007c25bd49c936 in _PyEvalFramePushAndInit (tstate=0x0, func=0x7c25bb0a6340, locals=0x0, args=0x0, argcount=0, kwnames=0x0) at ../Python/ceval.c:1589
#3 0x00007c25bd49d356 in _PyEval_Vector (tstate=0x0, func=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=<optimized out>) at ../Python/ceval.c:1677
#4 0x00007c25bd384b76 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=0, args=0x0, callable=<function at remote 0x7c25bb0a6340>, tstate=0x0) at ../Include/internal/pycore_call.h:92
#5 _PyObject_CallNoArgsTstate (func=<function at remote 0x7c25bb0a6340>, tstate=0x0) at ../Include/internal/pycore_call.h:99
#6 PyObject_CallObject (callable=<function at remote 0x7c25bb0a6340>, args=0x0) at ../Objects/call.c:469
#7 0x00006068dd746e50 in Python::execute (this=0x6068de412b50, eventsDb=0x6068de5208c0, namingmode=1, tmplExpression=0x7c25b0009c00 "") at python.c:310
#8 0x00006068dd6d3c2c in cEpgHttpd::storeTimerJob (this=0x6068de411d00, jInData=0x7c25b00093e0, response=0x7c25b0009300) at webstore.c:309
#9 0x00006068dd6ed227 in cEpgHttpd::performPostData (this=0x6068de411d00, url=0x7c25b0000e05 "/data/save-timer", data=0x7c25b87fe8e0) at httpd.c:1626
#10 0x00006068dd6edb4d in cEpgHttpd::dispatcher (cls=0x0, tcp=0x7c25b0000b70, url=0x7c25b0000e05 "/data/save-timer", method=0x7c25b0000e00 "POST", version=0x7c25b0000e16 "HTTP/1.1", upload_data=0x0, upload_data_size=0x7c25b87fecb0,
con_cls=0x7c25b0000c28) at httpd.c:1779
#11 0x00007c25bdc4f72e in call_connection_handler (connection=connection@entry=0x7c25b0000b70) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/connection.c:4366
#12 0x00007c25bdc521e8 in MHD_connection_handle_idle (connection=connection@entry=0x7c25b0000b70) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/connection.c:7329
#13 0x00007c25bdc555e8 in call_handlers (con=con@entry=0x7c25b0000b70, read_ready=<optimized out>, write_ready=<optimized out>, force_close=false) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:1320
#14 0x00007c25bdc56c61 in MHD_epoll (daemon=0x6068de7c20e0, millisec=<optimized out>) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:5766
#15 0x00007c25bdc60035 in MHD_polling_thread (cls=0x6068de7c20e0) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:6025
#16 0x00007c25bc29ca94 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#17 0x00007c25bc329c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
Display More
Dasselbe mit valgrind laufen lassen ergibt diesmal eine sehr lange Textdatei, s. Anhang valgrind.zip valgrind.zip.
Ehrlich gesagt, verstehe ich nun nicht, warum darin kein bisschen von der libmicrohttp die Rede ist...
Viele Grüße,
Chriss
Debug-Symbole nach https://ubuntu.com/server/docs/debug-symbol-packages für die libmicrohttpd), damit man sieht, was das genau vor den Crash abläuft?
Bin bis dort kurz davor gekommen und laufe beim apt-get update in diesen issue und muss wohl warten, bis das behoben ist:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1975865
Holen:1 http://ddebs.ubuntu.com noble InRelease [41,3 kB]
OK:2 http://de.archive.ubuntu.com/ubuntu noble InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu noble-updates InRelease
OK:4 http://de.archive.ubuntu.com/ubuntu noble-backports InRelease
Holen:5 http://ddebs.ubuntu.com noble-updates InRelease [41,3 kB]
Holen:6 http://ddebs.ubuntu.com noble-proposed InRelease [41,4 kB]
OK:7 http://security.ubuntu.com/ubuntu noble-security InRelease
Holen:8 http://ddebs.ubuntu.com noble-updates/main i386 Packages [42,1 kB]
Holen:9 http://ddebs.ubuntu.com noble-updates/main amd64 Packages [65,0 kB]
Holen:10 http://ddebs.ubuntu.com noble-updates/universe amd64 Packages [41,1 kB]
Holen:10 http://ddebs.ubuntu.com noble-updates/universe amd64 Packages [41,1 kB]
Fehl:10 http://ddebs.ubuntu.com noble-updates/universe amd64 Packages
Datei hat eine unerwartete Größe (40164 != 41132). Eventuell läuft gerade eine Spiegel-Synchronisierung? [IP: 2620:2d:4000:1::2b 80]
Hashes of expected file:
- Filesize:41132 [weak]
- SHA512:efc7767b1916f6e7091a91bb974d40ecf3b9a9c3f007e0c92654252d0235d39d0a75d416a834953c70a9b8fcdaa68d4384684bed87ded87887367ba2b8165fbc
- SHA256:8e46fc768637c9a73debc699bd1a4dda79a163a2c7c5461842041a4c8d9d2878
- SHA1:f54339492d83bc893d1923b19d97b5bbb7862f4a [weak]
- MD5Sum:43797958cb6938dfbae195e63e8e5d18 [weak]
Release file created at: Wed, 05 Jun 2024 16:46:36 +0000
Es wurden 82,7 kB in 0 s geholt (193 kB/s).
Paketlisten werden gelesen… Fertig
E: Fehlschlag beim Holen von http://ddebs.ubuntu.com/dists/noble-updates/universe/binary-amd64/Packages.xz Datei hat eine unerwartete Größe (40164 != 41132). Eventuell läuft gerade eine Spiegel-Synchronisierung? [IP: 2620:2d:4000:1::2b 80]
Hashes of expected file:
- Filesize:41132 [weak]
- SHA512:efc7767b1916f6e7091a91bb974d40ecf3b9a9c3f007e0c92654252d0235d39d0a75d416a834953c70a9b8fcdaa68d4384684bed87ded87887367ba2b8165fbc
- SHA256:8e46fc768637c9a73debc699bd1a4dda79a163a2c7c5461842041a4c8d9d2878
- SHA1:f54339492d83bc893d1923b19d97b5bbb7862f4a [weak]
- MD5Sum:43797958cb6938dfbae195e63e8e5d18 [weak]
Release file created at: Wed, 05 Jun 2024 16:46:36 +0000
E: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
Display More
ganz blöde Frage, die Meldung Cannot find function ... hast du nicht im Log des epghttpd ?
oder Failed to load ... ?
Nein, nicht zu sehen.
Bzw. welche Meldungen kommen bei Start nach Initialize python script?
Habe mal den hoffentlich relevanten Part vom epgd-Start, sowie epghttpd-Start rausgesucht (bei epgd gibt es die Zeile einmal, bei epghttpd doppelt!?):
2024-06-05T19:19:56.217616+02:00 HTPC systemd[1]: Starting epgd.service - Database driven EPG Data collector...
2024-06-05T19:19:56.223664+02:00 HTPC epgd: Set locale to 'en_US.UTF-8'
2024-06-05T19:19:56.223726+02:00 HTPC epgd: Calling sd_notify(READY=1$STATUS=Ready$MAINPID=18577$)
2024-06-05T19:19:56.223747+02:00 HTPC epgd: Info: Systemd watchdog not configured, epgd won't be sending keep-alive messages!
2024-06-05T19:19:56.223768+02:00 HTPC epgd: Loading uuid from '/etc/epgd/uuid' succeeded [A6D8097F-9E85-4086-BB79-43AE19F3375B]
2024-06-05T19:19:56.224368+02:00 HTPC epgd: Starting epgd
2024-06-05T19:19:56.224393+02:00 HTPC epgd: Initialize python script '/etc/epgd/recording.py'
2024-06-05T19:19:56.235398+02:00 HTPC epgd: Loading plugin: /usr/local/lib/epgd/plugins/libepgd-ABC.so
2024-06-05T19:19:56.240846+02:00 HTPC epgd: Loading plugin: /usr/local/lib/epgd/plugins/libepgd-DEF.so
2024-06-05T19:19:56.240892+02:00 HTPC epgd[18577]: Found unexpected parameter 'LogLevel', ignoring
2024-06-05T19:19:56.240923+02:00 HTPC epgd: Loading plugin: /usr/local/lib/epgd/plugins/libepgd-XYZ.so
2024-06-05T19:19:56.240945+02:00 HTPC epgd: Read 31 option from /etc/epgd/epgd.conf
2024-06-05T19:19:56.240965+02:00 HTPC epgd: Info: Calling mysql_library_init()
2024-06-05T19:19:56.240985+02:00 HTPC epgd: Calling mysql_init(18577)
2024-06-05T19:19:56.241007+02:00 HTPC epgd: SQL client character now 'utf8mb3'
2024-06-05T19:19:56.241029+02:00 HTPC epgd: Closing mysql connection and calling mysql_thread_end(18577)
2024-06-05T19:19:56.241060+02:00 HTPC epgd: Checking database connection ...
2024-06-05T19:19:56.241082+02:00 HTPC epgd: Calling mysql_init(18577)
2024-06-05T19:19:56.241104+02:00 HTPC epgd: Checking table structure and indices ...
2024-06-05T19:19:56.241123+02:00 HTPC epgd: Checking table 'analyse'
2024-06-05T19:19:56.249146+02:00 HTPC epgd: Checking table 'channelmap'
...
...
2024-06-05T19:20:43.929198+02:00 HTPC epghttpd: Read 31 option from /etc/epgd/epgd.conf
2024-06-05T19:20:43.929215+02:00 HTPC epghttpd: Initialize python script '/etc/epgd/recording.py'
2024-06-05T19:20:43.940722+02:00 HTPC epghttpd: Initialize python script '/etc/epgd/recording.py'
2024-06-05T19:20:43.941639+02:00 HTPC epghttpd: Dictionary '/etc/epgd/epg.dat' loaded
2024-06-05T19:20:43.941668+02:00 HTPC epghttpd: Info: Calling mysql_library_init()
2024-06-05T19:20:43.942180+02:00 HTPC epghttpd: Connecting to database at 'localhost:3306'
2024-06-05T19:20:43.942207+02:00 HTPC epghttpd: Calling mysql_init(19294)
2024-06-05T19:20:43.942335+02:00 HTPC epghttpd: SQL client character now 'utf8mb3'
2024-06-05T19:20:43.946348+02:00 HTPC systemd[1]: Started epghttpd.service - EPG HTTP Daemon that provides a web interface.
2024-06-05T19:20:43.946648+02:00 HTPC epghttpd: Info: Eloquence set to 'Error,Warning,Info,' => 0x0007
2024-06-05T19:20:43.950904+02:00 HTPC epghttpd: Calling mysql_init(19294)
2024-06-05T19:20:43.956202+02:00 HTPC epghttpd: Starting http server ...
2024-06-05T19:20:43.956268+02:00 HTPC epghttpd: Listener at port 8888 established, waiting for connections
2024-06-05T19:20:43.956287+02:00 HTPC epghttpd: Calling sd_notify(READY=1$STATUS=Ready$MAINPID=19294$)
2024-06-05T19:20:43.956339+02:00 HTPC epghttpd: Info: Systemd watchdog not configured, epgd won't be sending keep-alive messages! denn dann
...
Display More
Noch eine Frage:
Verstehe ich es richtig, dass auch bei erfolgreichem "Durchschleusen" der event Datenstruktur aus dem C++ Kompilat ins python-Modul, keine .pyc erzeugt wird?
Danke euch beiden fürs Dranbleiben und viele Grüße,
Chriss
Das event-Modul kommt aus dem C++ Code: https://github.com/horchi/vdr-plu…b/python.c#L172 ff. - d.h. ohne dass epgd/epghttpd den Python-Interpreter startet und ihm das Modul unterschiebt (https://github.com/horchi/vdr-plu…b/python.c#L223), wird man von außen nichts davon sehen.
Habe mir schon gedacht, dass ich etwas übersehe. Danke für die Erklärung!
Kannst du mal die Debug-Pakete für Python installieren (python3-dbg und libpython3-dbg und die Debug-Symbole nach https://ubuntu.com/server/docs/debug-symbol-packages für die libmicrohttpd), damit man sieht, was das genau vor den Crash abläuft?
Mache ich, sobald ich wieder an den Rechner komme.