aber TVSP geht nur 1 Woche
Der Vollständigkeit halber: Ist bei mir auch bis 7.8. vorhanden.
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:
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-…/master/lib/python.c#L172 ff. - d.h. ohne dass epgd/epghttpd den Python-Interpreter startet und ihm das Modul unterschiebt (https://github.com/horchi/vdr-…/master/lib/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.
Danke horchi!
Seltsam, dachte es sei ein generelles Problem, weil ich die recording.py halt auch so nicht (on-the-fly) compiliert bekomme (gibt keine recording.pyc).
Oder ich hab' ein Brett vor'm Kopf?!...
chriss@HTPC:/etc/epgd$ python recording.py
Traceback (most recent call last):
File "/etc/epgd/recording.py", line 27, in <module>
import event
ModuleNotFoundError: No module named 'event'
Ich frage mich halt, woher das event kommen soll, wenn nichts im gleichen Verzeichnis liegt, oder auch sonst im Quellcode nicht:
chriss@HTPC:/usr/local/src/vdr-git$ find ../vdr-epg-daemon-httpd.git/ -name "event*"
../vdr-epg-daemon-httpd.git/http/src/js/eventDetail.js
../vdr-epg-daemon-httpd.git/configs/eventsview-uti.sql
../vdr-epg-daemon-httpd.git/configs/eventsviewplain-3po.sql
../vdr-epg-daemon-httpd.git/configs/eventsviewplain.sql
../vdr-epg-daemon-httpd.git/configs/eventsview-horchi.sql
../vdr-epg-daemon-httpd.git/configs/eventsview-ck.sql
../vdr-epg-daemon-httpd.git/configs/eventsview-3po.sql
../vdr-epg-daemon-httpd.git/configs/eventsview.sql
../vdr-epg-daemon-httpd.git/configs/eventsview-perlbo.sql
Python ist 3.12.3-0ubuntu, s. Screenshots
Vielleicht ist es ja schon etwas sehr Simples, was du daraus siehst.
Oder hier die Ausgabe beim Crash mit valgrind:
chriss@HTPC:/$ valgrind --leak-check=full /usr/local/bin/epghttpd -c /etc/epgd
==13020==
==13020== HEAP SUMMARY:
==13020== in use at exit: 437,726 bytes in 30 blocks
==13020== total heap usage: 26,852 allocs, 26,822 frees, 18,028,394 bytes allocated
==13020==
==13020== 7,385 (152 direct, 7,233 indirect) bytes in 1 blocks are definitely lost in loss record 27 of 30
==13020== at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13020== by 0x1A2CA4: cEpgHttpd::initDb() (httpd.c:1042)
==13020== by 0x19DB26: cEpgHttpd::init() (httpd.c:199)
==13020== by 0x1A872C: main (httpd.c:2211)
==13020==
==13020== 34,841 (152 direct, 34,689 indirect) bytes in 1 blocks are definitely lost in loss record 28 of 30
==13020== at 0x4846FA3: operator new(unsigned long) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==13020== by 0x1A2B6C: cEpgHttpd::initDb() (httpd.c:1028)
==13020== by 0x19DB26: cEpgHttpd::init() (httpd.c:199)
==13020== by 0x1A872C: main (httpd.c:2211)
==13020==
==13020== LEAK SUMMARY:
==13020== definitely lost: 304 bytes in 2 blocks
==13020== indirectly lost: 41,922 bytes in 18 blocks
==13020== possibly lost: 0 bytes in 0 blocks
==13020== still reachable: 395,500 bytes in 10 blocks
==13020== suppressed: 0 bytes in 0 blocks
==13020== Reachable blocks (those to which a pointer was found) are not shown.
==13020== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==13020==
==13020== For lists of detected and suppressed errors, rerun with: -s
==13020== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
==13011== Thread 2 MHD-single:
==13011== Invalid read of size 8
==13011== at 0x4BB28D5: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0)
==13011== by 0x4B57935: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0)
==13011== by 0x4B58355: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0)
==13011== by 0x4A3FB75: PyObject_CallObject (in /usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0)
==13011== by 0x1FFE4F: Python::execute(cDbTable*, int, char const*) (python.c:310)
==13011== by 0x18CC2B: cEpgHttpd::storeTimerJob(json_t*, json_t*) (webstore.c:309)
==13011== by 0x1A6226: cEpgHttpd::performPostData(char const*, MemoryStruct*) (httpd.c:1626)
==13011== by 0x1A6B4C: cEpgHttpd::dispatcher(void*, MHD_Connection*, char const*, char const*, char const*, char const*, unsigned long*, void**) (httpd.c:1779)
==13011== by 0x488B72D: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.12.62.0)
==13011== by 0x488E1E7: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.12.62.0)
==13011== by 0x48915E7: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.12.62.0)
==13011== by 0x4892C60: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.12.62.0)
==13011== Address 0xf0 is not stack'd, malloc'd or (recently) free'd
==13011==
==13011==
==13011== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==13011== Access not within mapped region at address 0xF0
==13011== at 0x4BB28D5: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0)
==13011== by 0x4B57935: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0)
==13011== by 0x4B58355: ??? (in /usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0)
==13011== by 0x4A3FB75: PyObject_CallObject (in /usr/lib/x86_64-linux-gnu/libpython3.12.so.1.0)
==13011== by 0x1FFE4F: Python::execute(cDbTable*, int, char const*) (python.c:310)
==13011== by 0x18CC2B: cEpgHttpd::storeTimerJob(json_t*, json_t*) (webstore.c:309)
==13011== by 0x1A6226: cEpgHttpd::performPostData(char const*, MemoryStruct*) (httpd.c:1626)
==13011== by 0x1A6B4C: cEpgHttpd::dispatcher(void*, MHD_Connection*, char const*, char const*, char const*, char const*, unsigned long*, void**) (httpd.c:1779)
==13011== by 0x488B72D: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.12.62.0)
==13011== by 0x488E1E7: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.12.62.0)
==13011== by 0x48915E7: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.12.62.0)
==13011== by 0x4892C60: ??? (in /usr/lib/x86_64-linux-gnu/libmicrohttpd.so.12.62.0)
==13011== If you believe this happened as a result of a stack
==13011== overflow in your program's main thread (unlikely but
==13011== possible), you can try to increase the size of the
==13011== main thread stack using the --main-stacksize= flag.
==13011== The main thread stack size used in this run was 8388608.
==13011==
==13011== HEAP SUMMARY:
==13011== in use at exit: 7,280,340 bytes in 10,983 blocks
==13011== total heap usage: 27,130 allocs, 16,147 frees, 18,475,406 bytes allocated
==13011==
==13011== LEAK SUMMARY:
==13011== definitely lost: 7 bytes in 1 blocks
==13011== indirectly lost: 0 bytes in 0 blocks
==13011== possibly lost: 960 bytes in 2 blocks
==13011== still reachable: 7,279,373 bytes in 10,980 blocks
==13011== of which reachable via heuristic:
==13011== newarray : 69,336 bytes in 29 blocks
==13011== suppressed: 0 bytes in 0 blocks
==13011== Rerun with --leak-check=full to see details of leaked memory
==13011==
==13011== For lists of detected and suppressed errors, rerun with: -s
==13011== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Display More
Viele Grüße,
Chriss
Hi Horchi,
meinst du den Coredump?
Sehr gerne, habe ein paar anzubieten und sie am Issue in github hochgeladen.
Wegen der Dateinamensrestriktionen musst du vermutlich die eine umbennen (".zip entfernen"), um die beiden Zip-Teile entpacken zu können.
VDR ist 2.6.7
Danke schon bis hierher und viele Grüße,
Chriss
Ich antworte mir mal selber:
Durch Zufall habe ich gerade bemerkt, dass Timer erfolgreich ohne Segfault gespeichert werden, wenn diese bei "Ermittlung des Dateinamens" den Wert "VDR" gesetzt haben. Alle anderen Werte führen zum Absturz.
Sieht so aus, als sei dies tatsächlich auf den Aufruf der recording.py zurückzuführen... aus der Hilfe von epghttpd:
QuoteDer Dateinamen wird, mit Ausnahme des Mode 'VDR', über das Python Skript (/etc/epgd/recording.py) ermittelt, er kann bereits Pfadangaben erhalten.
- 0 VDR: Keine Ermittlung des Dateinamens, die Bezeichnung der Aufnahme wird dem VDR überlassen lediglich das unten angegebene Verzeichnis wird vorangestellt.
- 1 Auto: Automatische Auswahl des Mode Constable, Serie oder Kategorisiert
- 2 Constable: Dateinamen basierend auf Daten von Constabel (Titel/Staffel/xTeil-Nummer/Untertitel) sofern verfügbar
- 3 Serie: Serienaufnahme ohne Verwendung der Constabel Daten (Titel/Untertitel)
- 4 Kategorisiert: Einorden der Aufnahmen entsprechend der Film-Kategorie (Kategorie/Titel)
- 5 User: Hier kann man sich selbst im Python Skript verewigen
- 6 Template: Der Dateiname wird in Eingabefeld unten definiert, hierbei können Platzhalter (%...%) verwendet werden. Bei Eingabe von % erscheint die Auswahl der Platzhalter
recording.py macht ein import event, was wohl nicht funktioniert, da eine entsprechende Code-Datei nicht zu finden ist.
Wie dies zu beheben ist, weiß ich zwar noch nicht, aber ich habe nun zumindest einen Workaround.
Hallo zusammen,
nachdem epghttpd nun startet (s. [Solved] epghttpd mit Problemen beim Start (Kubuntu 24.04)), ist das Speichern von Timern nicht möglich. Dabei ist es egal, ob neue Timer oder beim Ändern eines Timers.
Ich bin jetzt erneut ratlos, ob dies an epghttpd liegt, oder an der libpython Version von Ubuntu 24.04. Konnte bisher nur so weit schauen, dass der Backtrace immer "gleich" aussieht, unabhängig davon, ob ein neuer Timer angelegt wird, wie viele Timer bereits existieren, ob ich einen bestehenden Timer ändere ... habe gedacht, dass ggfs. sonst der Paramter size bei _PyThreadState_PushFrame (tstate=tstate@entry=0x0, size=28) mal mit einem anderen Wert als 28 belegt sein würde ... size=28.
Ein tstate=0x0 sieht auch nicht so richtig gesund aus?!
Vielleicht hat jemand ähnliche Probleme (gehabt) oder sonst eine Idee, ob es wirklich ganz tief im System verbuddelt ist, oder "nur" an der Übergabe des Timers in die von epghttpd verwendeten Bibliotheken:
chriss@host:/$ coredumpctl debug
PID: 11214 (epghttpd)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Sat 2024-06-01 16:24:51 CEST (4min 7s 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-94e053523fbd4473813a32f18b53f20b.scope
Unit: user@1000.service
User Unit: app-org.kde.konsole-94e053523fbd4473813a32f18b53f20b.scope
Slice: user-1000.slice
Owner UID: 1000 (chriss)
Boot ID: aefd719ccdc24995bd044790d9116a32
Machine ID: 3e19bda874a04977b50b2196499bd616
Hostname: HTPC
Storage: /var/lib/systemd/coredump/core.epghttpd.0.aefd719ccdc24995bd044790d9116a32.11214.1717251891000000.zst (present)
Size on Disk: 1.3M
Message: Process 11214 (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.amd64
Module libarchive.so.13 from deb libarchive-3.7.2-2.amd64
Stack trace of thread 11217:
#0 0x000079ef50af78d5 n/a (libpython3.12.so.1.0 + 0x2f78d5)
#1 0x000079ef50a9c936 n/a (libpython3.12.so.1.0 + 0x29c936)
#2 0x000079ef50a9d356 n/a (libpython3.12.so.1.0 + 0x29d356)
#3 0x000079ef50984b76 PyObject_CallObject (libpython3.12.so.1.0 + 0x184b76)
#4 0x00005582668a9e50 _ZN6Python7executeEP8cDbTableiPKc (epghttpd + 0xf7e50)
#5 0x0000558266836c2c _ZN9cEpgHttpd13storeTimerJobEP6json_tS1_ (epghttpd + 0x84c2c)
#6 0x0000558266850227 _ZN9cEpgHttpd15performPostDataEPKcP12MemoryStruct (epghttpd + 0x9e227)
#7 0x0000558266850b4d _ZN9cEpgHttpd10dispatcherEPvP14MHD_ConnectionPKcS4_S4_S4_PmPS0_ (epghttpd + 0x9eb4d)
#8 0x000079ef5118272e n/a (libmicrohttpd.so.12 + 0xb72e)
#9 0x000079ef511851e8 n/a (libmicrohttpd.so.12 + 0xe1e8)
#10 0x000079ef511885e8 n/a (libmicrohttpd.so.12 + 0x115e8)
#11 0x000079ef51189c61 n/a (libmicrohttpd.so.12 + 0x12c61)
#12 0x000079ef51193035 n/a (libmicrohttpd.so.12 + 0x1c035)
#13 0x000079ef4f89ca94 start_thread (libc.so.6 + 0x9ca94)
#14 0x000079ef4f929c3c __clone3 (libc.so.6 + 0x129c3c)
Stack trace of thread 11214:
#0 0x000079ef4f8ecadf __GI___clock_nanosleep (libc.so.6 + 0xecadf)
#1 0x000079ef4f8f9a27 __GI___nanosleep (libc.so.6 + 0xf9a27)
#2 0x000079ef4f90ec63 __sleep (libc.so.6 + 0x10ec63)
#3 0x000055826684edc5 _ZN9cEpgHttpd4loopEv (epghttpd + 0x9cdc5)
#4 0x0000558266852798 main (epghttpd + 0xa0798)
#5 0x000079ef4f82a1ca __libc_start_call_main (libc.so.6 + 0x2a1ca)
#6 0x000079ef4f82a28b __libc_start_main_impl (libc.so.6 + 0x2a28b)
#7 0x0000558266835085 _start (epghttpd + 0x83085)
ELF object binary architecture: AMD x86-64
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-git
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.
[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 0x000079ef50af78d5 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 0x79ef4bc006c0 (LWP 11217))]
(gdb) bt
#0 0x000079ef50af78d5 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 0x000079ef50a9c936 in _PyEvalFramePushAndInit (tstate=0x0, func=0x79ef4c1da2a0, locals=0x0, args=0x0, argcount=0, kwnames=0x0) at ../Python/ceval.c:1589
#3 0x000079ef50a9d356 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 0x000079ef50984b76 in _PyObject_VectorcallTstate (kwnames=0x0, nargsf=0, args=0x0, callable=0x79ef4c1da2a0, tstate=0x0) at ../Include/internal/pycore_call.h:92
#5 _PyObject_CallNoArgsTstate (func=0x79ef4c1da2a0, tstate=0x0) at ../Include/internal/pycore_call.h:99
#6 PyObject_CallObject (callable=0x79ef4c1da2a0, args=0x0) at ../Objects/call.c:469
#7 0x00005582668a9e50 in Python::execute (this=0x5582670edb50, eventsDb=0x5582671fb0d0, namingmode=1, tmplExpression=0x79ef440098f0 "") at python.c:310
#8 0x0000558266836c2c in cEpgHttpd::storeTimerJob (this=0x5582670ecd00, jInData=0x79ef440093a0, response=0x79ef440092c0) at webstore.c:309
#9 0x0000558266850227 in cEpgHttpd::performPostData (this=0x5582670ecd00, url=0x79ef44000e05 "/data/save-timer", data=0x79ef4bbfe8e0) at httpd.c:1626
#10 0x0000558266850b4d in cEpgHttpd::dispatcher (cls=0x0, tcp=0x79ef44000b70, url=0x79ef44000e05 "/data/save-timer", method=0x79ef44000e00 "POST", version=0x79ef44000e16 "HTTP/1.1", upload_data=0x0, upload_data_size=0x79ef4bbfecb0, con_cls=0x79ef44000c28) at httpd.c:1779
#11 0x000079ef5118272e in call_connection_handler (connection=connection@entry=0x79ef44000b70) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/connection.c:4366
#12 0x000079ef511851e8 in MHD_connection_handle_idle (connection=connection@entry=0x79ef44000b70) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/connection.c:7329
#13 0x000079ef511885e8 in call_handlers (con=con@entry=0x79ef44000b70, 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 0x000079ef51189c61 in MHD_epoll (daemon=0x55826749c770, millisec=<optimized out>) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:5766
#15 0x000079ef51193035 in MHD_polling_thread (cls=0x55826749c770) at /build/libmicrohttpd-XeOg5r/libmicrohttpd-1.0.0/src/microhttpd/daemon.c:6025
#16 0x000079ef4f89ca94 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:447
#17 0x000079ef4f929c3c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78
(gdb)
Display More
Vielen Dank im Voraus und beste Grüße,
Chriss
Hallo rkp,
bei mir sehen die Settings in der Config so aus:
wobei bei mir die Geräte so sind (der Verstärker ist RX-V6A und an HDMI-0, Gerät 3 angeschlossen):
chriss@host:/$> aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC897 Analog [ALC897 Analog]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 3: HDMI 0 [RX-V6A]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 7: HDMI 1 [DELL U2717D]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 8: HDMI 2 [HDMI 2]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 9: HDMI 3 [HDMI 3]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Display More
Du musst dies hoffentlich "nur noch" auf deine Begebenheiten anpassen und solltest dann Sound haben.
Wobei es bei mir auch erst seit Ubuntu 23.10 und aktueller git-Version des Plugins geht.
Viele Grüße,
Chriss