segfault von epghttpd beim Speichern von Timern

theonlychriss · 1. Juni 2024

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:

Code

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)

Alles anzeigen

Vielen Dank im Voraus und beste Grüße,

Chriss

theonlychriss · 1. Juni 2024

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:

Zitat

Der 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.

horchi · 1. Juni 2024

Kannst du mir den BT posten bitte.

Welche VDR Version?

theonlychriss · 2. Juni 2024

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

horchi · 2. Juni 2024

Ein core dump passt in aller Regel nur zu dem System, der Programm Version, libs etc. mit welchen er entstanden ist.

Daher bitte einfach nur der (ASCI) BT (Back Trace) hier posten. Ich hoffe das ich damit sehe wo es klemmt.

horchi · 2. Juni 2024

Sorry !!!! ich sehe gerade das hast du oben im ersten Post schon dabei, habe es am Handy übersehen.

Ich sehe es mir an wenn ich wieder zuhause bin.

horchi · 4. Juni 2024

Habs mir angesehen, leider bis jetzt noch nichts gefunden. Wenn ich mir einen Timer Namen über das Skript erstellen lasse bekomme ich:

Code

Jun  4 15:20:12 gate epghttpd: Info: The recording name (mode=4) calculated by 'recording.py' is 'Spielfilm~Nachtschicht: Es lebe der Tod'

Auch valgrind zeigt mir nichts auffälliges.
Kannst du es bei dir auch mal mit valgrind laufen lassen?

Welche python Version verwendet du, also von welcher Version ist das 'dev' Paket installiert?

theonlychriss · 4. Juni 2024

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?!...

Code

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:

Code

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:

Code

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)

Alles anzeigen

Viele Grüße,

Chriss

seahawk1986 · 4. Juni 2024

Zitat von theonlychriss

Ich frage mich halt, woher das event kommen soll, wenn nichts im gleichen Verzeichnis liegt, oder auch sonst im Quellcode nicht:

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.

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?

theonlychriss · 5. Juni 2024

Zitat von seahawk1986

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!

Zitat von seahawk1986

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.

horchi · 5. Juni 2024

ganz blöde Frage, die Meldung Cannot find function ... hast du nicht im Log des epghttpd ?
oder Failed to load ... ?

horchi · 5. Juni 2024

Bzw. welche Meldungen kommen bei Start nach Initialize python script?

theonlychriss · 5. Juni 2024

Zitat von seahawk1986

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:

Bug #1975865 “Hash and size mismatch with http://ddebs.ubuntu.co...” : Bugs : apt package : Ubuntu

When adding the debug repos, I am getting: E: Failed to fetch http://ddebs.ubuntu.com/dists/bionic-updates/main/binary-amd64/Packages.gz File has unexpected…

bugs.launchpad.net

Code

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.

Alles anzeigen

Zitat von horchi

ganz blöde Frage, die Meldung Cannot find function ... hast du nicht im Log des epghttpd ?
oder Failed to load ... ?

Nein, nicht zu sehen.

Zitat von horchi

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!?):

Code

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
...

Alles anzeigen

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

seahawk1986 · 5. Juni 2024

Zitat von theonlychriss

Bin bis dort kurz davor gekommen und laufe beim apt-get update in diesen issue und muss wohl warten, bis das behoben ist:

Eventuell reichen die Debug-Pakete für Python schon, da scheint ja irgendetwas nach dem Aufruf von PyObject_CallObject schiefzugehen, also wo er aus dem C++-Code eine Python-Funktion aufruft.

theonlychriss · 6. Juni 2024

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?!

Code

$ 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

Alles anzeigen

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

horchi · 7. Juni 2024

pull mal die neuste Version aus dem git, wechsle in den lib Ordner und baue das pytst:

Code

cd lib
make pytst

dann aufrufen (./pytst) und entsprechend der Usage Ausgabe verwenden.
Damit kannst du des Python Skript Aufruf aus dem c++ Code heraus testen. Wenn das geht liegt das Problem an anderer Stelle. Wenn es nicht geht müssen wir viel weniger Code debuggen.

theonlychriss · 9. Juni 2024

Hi horchi,

danke vielmals für das mini-How-To. Resultat ist:

Code

$ ./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

horchi · 10. Juni 2024

zumindest wissen wir nun das der Python Aufruf aus C++ funktioniert. Der Code dazu welchen der epghttpd verwendet ist der selbe.
Entweder etwas rundrum, zum Beispiel das der epghttpd zwei Instanzen davon verwendet oder ein ganz anderer Fehler welchen den Speicher vorher schreddert.

Vielleicht als nächstes die andere Stelle mal auskommentieren und schauen was dann passiert.

horchi · 10. Juni 2024

Versuchs mal hiermit:

Diff

root@gate {master u=} ~/source/epgd> git diff lib/searchtimer.c lib/searchtimer.h 
diff --git a/lib/searchtimer.c b/lib/searchtimer.c
index 4a958a4..902f41a 100644
--- a/lib/searchtimer.c
+++ b/lib/searchtimer.c
@@ -80,21 +80,21 @@ cSearchTimer::cSearchTimer(cFrame* aParent)
 
    lastSearchTimerUpdate = 0;
 
-   ptyRecName = new Python("recording", "name");
+   // ptyRecName = new Python("recording", "name");
 }
 
 cSearchTimer::~cSearchTimer()
 {
-   delete ptyRecName;
+   // delete ptyRecName;
 }
 
 int cSearchTimer::init(const char* confDir)
 {
-   if (ptyRecName->init(confDir) != success)
-   {
-      tell("Error: Init of python script recording.py failed, aborting");
-      return fail;
-   }
+   // if (ptyRecName->init(confDir) != success)
+   // {
+   //    tell("Error: Init of python script recording.py failed, aborting");
+   //    return fail;
+   // }
 
    return done;
 }
@@ -784,19 +784,19 @@ int cSearchTimer::checkTimers()
       {
          // execute python - calc recording name
 
-         if (ptyRecName->execute(useeventsDb, namingmode, tmplExpression) == success)
-         {
-            if (!timerDb->hasValue("FILE", ptyRecName->getResult()))
-            {
-               parent->message(0, 'I', "EPGD: Timer action", "Calculated name of event (%ld) changed from '%s' to '%s', updating timer (%ld)!",
-                               timerDb->getIntValue("EVENTID"), timerDb->getStrValue("FILE"),
-                               ptyRecName->getResult(), timerDb->getIntValue("ID"));
-
-               timerDb->setValue("FILE", ptyRecName->getResult());
-               modifyTimer(timerDb, timerDb->hasCharValue("ACTION", taCreate) ? taCreate : taModify);
-               count++;
-            }
-         }
+         // if (ptyRecName->execute(useeventsDb, namingmode, tmplExpression) == success)
+         // {
+         //    if (!timerDb->hasValue("FILE", ptyRecName->getResult()))
+         //    {
+         //       parent->message(0, 'I', "EPGD: Timer action", "Calculated name of event (%ld) changed from '%s' to '%s', updating timer (%ld)!",
+         //                       timerDb->getIntValue("EVENTID"), timerDb->getStrValue("FILE"),
+         //                       ptyRecName->getResult(), timerDb->getIntValue("ID"));
+
+         //       timerDb->setValue("FILE", ptyRecName->getResult());
+         //       modifyTimer(timerDb, timerDb->hasCharValue("ACTION", taCreate) ? taCreate : taModify);
+         //       count++;
+         //    }
+         // }
       }
 
       selectEvent->freeResult();
@@ -1352,14 +1352,14 @@ int cSearchTimer::createTimer(int id)
    {
       // execupe python - calc recording name
 
-      if (ptyRecName->execute(useeventsDb, namingmode, tmplExpression) == success)
-      {
-         tell(eloSearch, "Info: The recording name calculated by 'recording.py' is '%s'",
-              ptyRecName->getResult());
+      // if (ptyRecName->execute(useeventsDb, namingmode, tmplExpression) == success)
+      // {
+      //    tell(eloSearch, "Info: The recording name calculated by 'recording.py' is '%s'",
+      //         ptyRecName->getResult());
 
-         if (!isEmpty(ptyRecName->getResult()))
-            timerRow.setValue("FILE", ptyRecName->getResult());
-      }
+      //    if (!isEmpty(ptyRecName->getResult()))
+      //       timerRow.setValue("FILE", ptyRecName->getResult());
+      // }
    }
 
    // for 'event' based timers, check on failed attemps for this eventid
diff --git a/lib/searchtimer.h b/lib/searchtimer.h
index 66efd57..58b3eca 100644
--- a/lib/searchtimer.h
+++ b/lib/searchtimer.h
@@ -69,7 +69,7 @@ class cSearchTimer
 
       // data
 
-      Python* ptyRecName {};
+      // Python* ptyRecName {};
 
       cDbConnection* connection {};

Alles anzeigen

Ist nur ein Test um es einzugrenzen, keine Lösung. Dden epgd würde ich damit nicht tauschen nur den ephghttpd sonst hebelst du auch dort das generieren der Namen aus.

theonlychriss · 10. Juni 2024

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:

Code

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!

Alles anzeigen

Und dies habe ich bisher noch nicht gesehen, scheint mir aber eine ganz andere Baustelle und somit Zufallsfund zu sein:

Code

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:

Code

#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

Alles anzeigen

Bin wieder und weiterhin ratlos.

segfault von epghttpd beim Speichern von Timern

Jetzt mitmachen!

Teilen