[gelöst] segfault von epghttpd beim Speichern von Timern

Hallo horchi ,

sorry für die späte Antwort, ich hatte es gelesen und wieder verdrängt
Vorab, das mit dem Kopieren des DIFFs funktioniert nicht, es sind zu viele unnütze Zeilenumbrüche enthalten.

Keine Ahnung ob das vielleicht von der Forumsoftware verursacht wird. Vielleicht können wir es mal mit einer Textdatei versuchen.

Leider ist der Patch noch nicht die Lösung.

Es wird alles gebaut, epgd und epghttpd starten auch, es ist aber nicht möglich per Web einen Timer zu programmieren.

Ich habe versucht aus dem "Magazin" einen Timer zu erstellen:

Log: journalctl -f --priority=debug -u epghttpd

Quote

Aug 21 17:10:27 test-epgd systemd[1]: epghttpd.service: Main process exited, code=dumped, status=11/SEGV

Aug 21 17:10:27 test-epgd systemd[1]: epghttpd.service: Failed with result 'core-dump'.

Aug 21 17:10:27 test-epgd systemd[1]: epghttpd.service: Scheduled restart job, restart counter is at 1.

Aug 21 17:10:27 test-epgd systemd[1]: Starting epghttpd.service - epghttpd provides a webinterface for epg data...

Dump:

Quote

root@test-epgd:~# coredumpctl debug

PID: 1524 (epghttpd)

UID: 0 (root)

GID: 0 (root)

Signal: 11 (SEGV)

Timestamp: Wed 2024-08-21 17:10:26 CEST (49s ago)

Command Line: /usr/bin/epghttpd -n -c /etc/epgd

Executable: /usr/bin/epghttpd

Control Group: /system.slice/epghttpd.service

Unit: epghttpd.service

Slice: system.slice

Boot ID: de6f26a830064ca396ded8bf64139429

Machine ID: 146b85d4f08f4d21a93afcdbc705b5b7

Hostname: test-epgd

Storage: /var/lib/systemd/coredump/core.epghttpd.0.de6f26a830064ca396ded8bf64139429.1524.1724253026000000.zst (present)

Size on Disk: 1.9M

Message: Process 1524 (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.2.amd64

Module libarchive.so.13 from deb libarchive-3.7.2-2ubuntu0.1.amd64

Stack trace of thread 1573:

#0 0x000076bf69af78d5 n/a (libpython3.12.so.1.0 + 0x2f78d5)

#1 0x000076bf69a9c936 n/a (libpython3.12.so.1.0 + 0x29c936)

#2 0x000076bf69a9d356 n/a (libpython3.12.so.1.0 + 0x29d356)

#3 0x000076bf69984b76 PyObject_CallObject (libpython3.12.so.1.0 + 0x184b76)

#4 0x00005555d1127742 _ZN6Python7executeEP8cDbTableiPKc (epghttpd + 0x8e742)

#5 0x00005555d10b8734 _ZN9cEpgHttpd13storeTimerJobEP6json_tS1_ (epghttpd + 0x1f734)

#6 0x00005555d10d1b29 _ZN9cEpgHttpd15performPostDataEPKcP12MemoryStruct (epghttpd + 0x38b29)

#7 0x00005555d10d244f _ZN9cEpgHttpd10dispatcherEPvP14MHD_ConnectionPKcS4_S4_S4_PmPS0_ (epghttpd + 0x3944f)

#8 0x000076bf6a19572e n/a (libmicrohttpd.so.12 + 0xb72e)

#9 0x000076bf6a1981e8 n/a (libmicrohttpd.so.12 + 0xe1e8)

#10 0x000076bf6a19b5e8 n/a (libmicrohttpd.so.12 + 0x115e8)

#11 0x000076bf6a19cc61 n/a (libmicrohttpd.so.12 + 0x12c61)

#12 0x000076bf6a1a6035 n/a (libmicrohttpd.so.12 + 0x1c035)

#13 0x000076bf6889ca94 start_thread (libc.so.6 + 0x9ca94)

#14 0x000076bf68929c3c __clone3 (libc.so.6 + 0x129c3c)

Stack trace of thread 1524:

#0 0x000076bf688ecadf __GI___clock_nanosleep (libc.so.6 + 0xecadf)

#1 0x000076bf688f9a27 __GI___nanosleep (libc.so.6 + 0xf9a27)

#2 0x000076bf6890ec63 __sleep (libc.so.6 + 0x10ec63)

#3 0x00005555d10d06c7 _ZN9cEpgHttpd4loopEv (epghttpd + 0x376c7)

#4 0x00005555d10d409a main (epghttpd + 0x3b09a)

#5 0x000076bf6882a1ca __libc_start_call_main (libc.so.6 + 0x2a1ca)

#6 0x000076bf6882a28b __libc_start_main_impl (libc.so.6 + 0x2a28b)

#7 0x00005555d10b5085 _start (epghttpd + 0x1c085)

ELF object binary architecture: AMD x86-64

Display More

P.S.:
Die Verwendung der "Code" oder "Inline-Code" Funktion hier im Forum fügt die Leerzeilen hinzu, mit "Zitat" passiert dies nicht.

Noch ein Gedanke zu diesem Thema.
Warum tritt der Fehler nur auf, wenn ich einen Timer manuell anlege oder ändere?
Suchtimer sind nicht betroffen und können den Namen mit Hilfe der recording.py ermitteln.
Wo ist hier der Unterschied.

Quote from minixjr

Noch ein Gedanke zu diesem Thema.
Warum tritt der Fehler nur auf, wenn ich einen Timer manuell anlege oder ändere?
Suchtimer sind nicht betroffen und können den Namen mit Hilfe der recording.py ermitteln.
Wo ist hier der Unterschied.

also auf deine letzte Frage hätte ich ne Antwort.

Sorry, kann ich nicht nachvollziehen .
Die Einstellungen sind bei mir identisch.
Wenn ich aus dem Magazin versuche einen Timer mit AUTO/AUTO manuell anzulegen gibt es einen Crash.
Macht es ein Suchtimer mit AUTO/AUTO nicht.
Ich sehe den Unterschied nicht.

Ich hoffe dieser Workaround funktioniert für alle die schon Python 3.12 nutzen.
So oder abgeleitet, hier am Beispiel yavdr (Ubuntu 24.04, noble)

Anmelden per SSH!

--> ALS NORMALER USER, im entsprechenden Home-Verzeichnis

# Siehe auch: https://github.com/pyenv/pyenv

curl https://pyenv.run | bash

--> Hinzufügen zur Datei ~/.bashrc

-------------------------------------------------------------------------

# Load pyenv automatically by appending
# the following to
# ~/.bash_profile if it exists, otherwise ~/.profile (for login shells)
# and ~/.bashrc (for interactive shells) :

export PYENV_ROOT="$HOME/.pyenv"
[[ -d $PYENV_ROOT/bin ]] && export PATH="$PYENV_ROOT/bin:$PATH"
eval "$(pyenv init -)"

# Restart your shell for the changes to take effect.

# Load pyenv-virtualenv automatically by adding
# the following to ~/.bashrc:

eval "$(pyenv virtualenv-init -)"

-------------------------------------------------------------------------

--> pyenv

pyenv update
pyenv install 3.11.9
pyenv global 3.11.9

--> Quellen laden

sudo apt install build-essential fakeroot devscripts
sudo apt-get build-dep vdr-epg-daemon
mkdir -p ~/src/epgd
cd  ~/src/epgd
apt-get source vdr-epg-daemon
cd vdr-epg-daemon*

--> patchen

-> Make.conf

PYTHON ?= python3 --> PYTHON ?= python3.11

-> debian/rules --> [TAB] nach dem Einfügen durch Taste "Tab" ersetzen !

override_dh_shlibdeps:
[TAB]dh_shlibdeps --dpkg-shlibdeps-params=--ignore-missing-info

--> Pakete bauen

dpkg-buildpackage -b -uc -us

--> Pakete installieren

cd ..
sudo dpkg -i *.deb

--> Reboot

was lange währt ....

Nachdem ich meinen Server auf Ubuntu 24.04 aktualisiert habe ich ich nun auch in den 'Genuss' von libpython 3.12 gekommen.
So konnte ich es reproduzieren und nach langer Suche beheben. Der Ansatz meines letzten Versuchs via PyGILState_Ensure() / PyGILState_Release war richtig.
Gefehlt hatte nur noch das Freigeben des Locks welche die Lib automatisch beim Initialisieren für dem Main-Thread anlegt - genau das ist Bescheiden bis nicht dokumentiert (sofern ich nicht ganz blind bin).

Lange Rede ... mit der neusten epgs/epghttpd Version (1.3.25) im Git sollte das Problem nicht mehr auftreten.

LG Jörg

Quote from minixjr

Noch ein Gedanke zu diesem Thema.
Warum tritt der Fehler nur auf, wenn ich einen Timer manuell anlege oder ändere?
Suchtimer sind nicht betroffen und können den Namen mit Hilfe der recording.py ermitteln.
Wo ist hier der Unterschied.

weil er nur bei manueller Anlage via WEBIF vom epghttpd angelegt wird und nur dort in einem Thread.

horchi,

super, danke, auch bei mir wieder alles OK