Okay selbes Resultat also an den beiden Instanzen des Python Wrapper liegt es schon mal nicht.
m.E. wird (sofern es am epghttpd liegt, wovon ich ausgehe) etwas im Speicher überschrieben.
Komisch ist nur das Valgrind dazu nichts anzeigt.
Hast du mal versucht es mit FORTIFY oder Stack Protection übersetz? Ggf bringt das Licht ins Dunkel
ja genau. Definiere dir am besten dieses Macro im Make.config
CFLAGS_MEM = -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
CFLAGS_MEM += -fcf-protection=full -Wtrampolinesund hänge es an die CFLAGS dran:
CFLAGS += $(CFLAGS_MEM) -O2dann alles neu bauen
make clean
make beim make solltest du dann sehen das die Optionen verwendet werden
Als Patch:
diff --git a/Make.config b/Make.config
index 840a61c..b00abc6 100644
--- a/Make.config
+++ b/Make.config
@@ -73,6 +73,13 @@ USEWOL = 1
USES = -DUSEUUID -DUSEMD5 -DUSELIBXML -DUSELIBARCHIVE -DUSEJSON -DUSEGUNZIP
DEFINES += -D_GNU_SOURCE -DBINDEST='"$(BINDEST)"' -DTARGET='"$(TARGET)"' -DLOG_PREFIX='""' -DPLGDIR='"$(PLGDEST)"' $(USES)
+CFLAGS_MEM = -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
+CFLAGS_MEM += -fcf-protection=full -Wtrampolines
+
+# CFLAGS += $(CFLAGS_MEM) -O2
+
ifeq "$(INIT_SYSTEM)" "systemd"
SYSD_NOTIFY = 1
endifdas ist kein Fix hilft aber ggf. um dem Problem auf die Spur zu kommen.
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:78Ist ü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 ...
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?):
ja, sorry hatte ich übersehen:
aber wie kommt man nun dem Problem besser auf die Spur?
Sieht immer noch gleich aus für meine Augen:
in den Fall hat es wie es aussieht nicht geholfen. Diese Einstellungen bewirken das (in bestimmten Situationen) Stack Fehler, Buffer-Overflows etc. erkannt und direkt mir SEGFAULT abgebrochen wird wodurch man die auslösende Stelle besser eingrenzen kann. Hier hat es wohl nicht zugeschlagen. Das ganze war ausgehend von der Vermutung das der Crash in der Python Lib nur ein Folgefehler ist (wovon ich immer noch ausgehe). Hab gerade auch keine Idee mehr wie man dem auf die Schliche kommen könnte.
Generell läuft meine Implementierung rund um die Python C++ lib ja, zum einen im epgd und zum anderen auch im Test Programm.
Hi,
habe hier das gleiche Problem. Coredump beim Anlegen von timern, die nicht auf 'VDR' gestellt werden.
Ich poste mal den bt, vielleicht hilft's.
Christian
web /var/lib/systemd/coredump # coredumpctl debug
PID: 1413 (epghttpd)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Wed 2024-06-19 22:07:27 CEST (9s ago)
Command Line: /usr/bin/epghttpd -c /etc/epgd
Executable: /usr/bin/epghttpd
Control Group: /system.slice/epghttpd.service
Unit: epghttpd.service
Slice: system.slice
Boot ID: 5b166cb376ba493e81a44b8b831d9572
Machine ID: 83039f6c679c90a840bd10b25b1fce02
Hostname: web
Storage: /var/lib/systemd/coredump/core.epghttpd.0.5b166cb376ba493e81a44b8b831d9572.1413.1718827647000000.zst (present)
Size on Disk: 1014.5K
Message: Process 1413 (epghttpd) of user 0 dumped core.
GNU gdb (Gentoo 14.2 vanilla) 14.2
Copyright (C) 2023 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
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/bin/epghttpd...
Reading symbols from /usr/lib/debug//usr/bin/epghttpd.debug...
[New LWP 1414]
[New LWP 1413]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Core was generated by `/usr/bin/epghttpd -c /etc/epgd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f68cae2a7b4 in ?? () from /usr/lib64/libpython3.12.so.1.0
[Current thread is 1 (Thread 0x7f68c89196c0 (LWP 1414))]
(gdb) bt
#0 0x00007f68cae2a7b4 in ?? () from /usr/lib64/libpython3.12.so.1.0
#1 0x00007f68cadd5c42 in ?? () from /usr/lib64/libpython3.12.so.1.0
#2 0x00007f68cadd7895 in ?? () from /usr/lib64/libpython3.12.so.1.0
#3 0x00007f68cace6d36 in PyObject_CallObject () from /usr/lib64/libpython3.12.so.1.0
#4 0x000055ce649ae354 in Python::execute (this=0x55ce660fc030, eventsDb=0x55ce661d61b0, namingmode=1, tmplExpression=0x7f68c4009a00 "")
at python.c:310
#5 0x000055ce6493ba78 in cEpgHttpd::storeTimerJob (this=0x55ce660fb1e0, jInData=0x7f68c4009330, response=0x7f68c4009250) at webstore.c:309
#6 0x000055ce64954cf2 in cEpgHttpd::performPostData (this=0x55ce660fb1e0, url=0x7f68c4000d75 "/data/save-timer", data=0x7f68c8917b20)
at httpd.c:1624
#7 0x000055ce64955610 in cEpgHttpd::dispatcher (cls=0x0, tcp=0x7f68c4000b70, url=0x7f68c4000d75 "/data/save-timer", method=0x7f68c4000d70 "POST",
version=0x7f68c4000d86 "HTTP/1.1", upload_data=0x0, upload_data_size=0x7f68c8917ef0, con_cls=0x7f68c4000bc8) at httpd.c:1777
#8 0x00007f68cb34da0c in ?? () from /usr/lib64/libmicrohttpd.so.12
#9 0x00007f68cb34fbf8 in ?? () from /usr/lib64/libmicrohttpd.so.12
#10 0x00007f68cb3525e0 in ?? () from /usr/lib64/libmicrohttpd.so.12
#11 0x00007f68cb357da0 in ?? () from /usr/lib64/libmicrohttpd.so.12
#12 0x00007f68cb358d05 in ?? () from /usr/lib64/libmicrohttpd.so.12
#13 0x00007f68c9ebf551 in ?? () from /usr/lib64/libc.so.6
#14 0x00007f68c9f2d92c in ?? () from /usr/lib64/libc.so.6
(gdb)Log dazu:
Jun 19 22:07:27 web kernel: MHD-single[1414]: segfault at f0 ip 00007f68cae2a7b4 sp 00007f68c8917380 error 4 in libpython3.12.so.1.0[7f68cac83000+243000] likely on CPU 0 (core 0, socket 0)
Jun 19 22:07:27 web kernel: Code: 06 00 00 0f 95 c0 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 41 55 41 54 55 49 89 f4 53 48 89 fd 48 83 ec 08 <48> 8b 97 f0 00 00 00 48 85 d2 74 1a 48 8b 87 f8 00 00 00 48 63 ce
Jun 19 22:07:27 web systemd[1]: Started Process Core Dump (PID 1470/UID 0).
Jun 19 22:07:27 web systemd-coredump[1471]: elfutils disabled, parsing ELF objects not supported
Jun 19 22:07:27 web systemd-coredump[1471]: [🡕] Process 1413 (epghttpd) of user 0 dumped core.
Jun 19 22:07:27 web systemd[1]: epghttpd.service: Main process exited, code=dumped, status=11/SEGV
Jun 19 22:07:27 web systemd[1]: epghttpd.service: Failed with result 'core-dump'.
Jun 19 22:07:27 web systemd[1]: systemd-coredump@2-1470-0.service: Deactivated successfully.
Jun 19 22:07:28 web systemd[1]: epghttpd.service: Scheduled restart job, restart counter is at 2.
Jun 19 22:07:28 web systemd[1]: Starting EPG HTTP Daemon that provides a web interface...
Jun 19 22:07:28 web epghttpd[1483]: Set locale to 'de_DE.utf8'
Jun 19 22:07:28 web epghttpd[1483]: detected UTF-8
Jun 19 22:07:28 web epghttpd[1483]: Read 27 option from /etc/epgd/epgd.conf
Jun 19 22:07:28 web epghttpd[1483]: Initialize python script '/etc/epgd/recording.py'
Jun 19 22:07:28 web systemd[1]: Started EPG HTTP Daemon that provides a web interface.
Jun 19 22:07:28 web epghttpd[1483]: Initialize python script '/etc/epgd/recording.py'
Jun 19 22:07:28 web epghttpd[1483]: Dictionary '/etc/epgd/epg.dat' loaded
Jun 19 22:07:28 web epghttpd[1483]: Info: Calling mysql_library_init()
Jun 19 22:07:28 web epghttpd[1483]: Connecting to database at 'localhost:3306'
Jun 19 22:07:28 web epghttpd[1483]: Calling mysql_init(1483)
Jun 19 22:07:28 web epghttpd[1483]: SQL client character now 'utf8mb3'
Jun 19 22:07:28 web epghttpd[1483]: Info: Eloquence set to 'Error,Warning,Info' => 0x0007
Jun 19 22:07:28 web epghttpd[1483]: Calling mysql_init(1483)
Jun 19 22:07:28 web epghttpd[1483]: Starting http server ...
Jun 19 22:07:28 web epghttpd[1483]: Listener at port 9999 established, waiting for connections
Jun 19 22:07:28 web epghttpd[1483]: Calling sd_notify(READY=1$STATUS=Ready$MAINPID=1483$)
Jun 19 22:07:28 web epghttpd[1483]: Info: Systemd watchdog not configured, epgd won't be sending keep-alive messages!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
hast du auch schonmal versucht, epghttpd so zu bauen, wie horchi hier in Beitrag #23 segfault von epghttpd beim Speichern von Timern vorgeschlagen hat?
gerade gemacht:
web /usr/local/portage/local/media-tv/epgd # coredumpctl debug
PID: 17132 (epghttpd)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Thu 2024-06-20 20:35:07 CEST (5min ago)
Command Line: ./epghttpd -c /etc/epgd
Executable: /var/tmp/portage/media-tv/epgd-9999/work/epgd-9999/epghttpd
Control Group: /user.slice/user-0.slice/session-18.scope
Unit: session-18.scope
Slice: user-0.slice
Session: 18
Owner UID: 0 (root)
Boot ID: 5a4a45de68c1405d887e869f80472527
Machine ID: 83039f6c679c90a840bd10b25b1fce02
Hostname: web
Storage: /var/lib/systemd/coredump/core.epghttpd.0.5a4a45de68c1405d887e869f80472527.17132.1718908507000000.zst (present)
Size on Disk: 2.6M
Message: Process 17132 (epghttpd) of user 0 dumped core.
GNU gdb (Gentoo 14.2 vanilla) 14.2
Copyright (C) 2023 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-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://bugs.gentoo.org/>.
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 /var/tmp/portage/media-tv/epgd-9999/work/epgd-9999/epghttpd...
[New LWP 17134]
[New LWP 17132]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Core was generated by `./epghttpd -c /etc/epgd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fa4a662a7b4 in ?? () from /usr/lib64/libpython3.12.so.1.0
[Current thread is 1 (Thread 0x7fa4a41d86c0 (LWP 17134))]
(gdb) bt
#0 0x00007fa4a662a7b4 in ?? () from /usr/lib64/libpython3.12.so.1.0
#1 0x00007fa4a65d5c42 in ?? () from /usr/lib64/libpython3.12.so.1.0
#2 0x00007fa4a65d7895 in ?? () from /usr/lib64/libpython3.12.so.1.0
#3 0x00007fa4a64e6d36 in PyObject_CallObject () from /usr/lib64/libpython3.12.so.1.0
#4 0x00005571ce816d62 in Python::execute (this=0x5571cff65ff0, eventsDb=0x5571d003dd20, namingmode=1, tmplExpression=0x7fa49c015420 "") at python.c:310
#5 0x00005571ce790f0d in cEpgHttpd::storeTimerJob (this=this@entry=0x5571cff651e0, jInData=jInData@entry=0x7fa49c028710, response=response@entry=0x7fa49c013ff0) at webstore.c:309
#6 0x00005571ce7b43f5 in cEpgHttpd::performPostData (this=0x5571cff651e0, url=url@entry=0x7fa49c019a65 "/data/save-timer", data=data@entry=0x7fa4a41d6830) at httpd.c:1624
#7 0x00005571ce7b4850 in cEpgHttpd::dispatcher (cls=<optimized out>, tcp=0x7fa49c0061b0, url=0x7fa49c019a65 "/data/save-timer", method=0x7fa49c019a60 "POST", version=<optimized out>, upload_data=0x0, upload_data_size=0x7fa4a41d6ef0,
con_cls=0x7fa49c006208) at httpd.c:1777
#8 0x00007fa4a6bb1a0c in ?? () from /usr/lib64/libmicrohttpd.so.12
#9 0x00007fa4a6bb3bf8 in ?? () from /usr/lib64/libmicrohttpd.so.12
#10 0x00007fa4a6bb65e0 in ?? () from /usr/lib64/libmicrohttpd.so.12
#11 0x00007fa4a6bbbda0 in ?? () from /usr/lib64/libmicrohttpd.so.12
#12 0x00007fa4a6bbcd05 in ?? () from /usr/lib64/libmicrohttpd.so.12
#13 0x00007fa4a56bf551 in ?? () from /usr/lib64/libc.so.6
#14 0x00007fa4a572d92c in ?? () from /usr/lib64/libc.so.6
(gdb)Bringt vermutlich auch keine Erleuchtung.
Hallo zusammen,
ich muss mich hier leider auch einklinken, nach dem Upgrade von Ubuntu focal zu noble (yavdr) habe ich das selbe Problem. 
Nachdem ich die Sourcen des Paketes per ppa runtergeladen und versucht habe es manuell zu bauen, sind mir deprecated Warnungen für Curl aufgefallen. Könnten die vielleicht was mit dem Problem zu tun haben?
Compile curl ..
g++ -c -I/usr/include/mariadb -I/usr/include/mariadb/mysql -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 -ggdb -O0 -I/usr/include/mariadb -I/usr/include/mariadb/mysql -D_GNU_SOURCE -DBINDEST='"/usr//bin"' -DTARGET='""' -DLOG_PREFIX='""' -DPLGDIR='"/usr//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 -DUSEUUID -DUSEMD5 -DUSELIBXML -DUSELIBARCHIVE -DUSEJSON -DUSEGUNZIP -DSYSDWDIFO -DUSESYSD curl.c -o curl.o
curl.c: In member function ‘int cCurl::PostUrl(const char*, const std::string&, std::string*, const std::string&)’:
curl.c:353:40: warning: ‘CURLFORM_COPYNAME’ is deprecated: since 7.56.0. Use curl_mime_name() [-Wdeprecated-declarations]
353 | curl_formadd(&formpost, &lastptr, CURLFORM_COPYNAME, sName.c_str(), CURLFORM_COPYCONTENTS, sValue.c_str(), CURLFORM_END);
| ^~~~~~~~~~~~~~~~~
In file included from curl.h:10,
from curl.c:8:
/usr/include/x86_64-linux-gnu/curl/curl.h:2501:3: note: declared here
2501 | CURLFORM_COPYNAME CURL_DEPRECATED(7.56.0, "Use curl_mime_name()"),
| ^~~~~~~~~~~~~~~~~
curl.c:353:74: warning: ‘CURLFORM_COPYCONTENTS’ is deprecated: since 7.56.0. Use curl_mime_data() [-Wdeprecated-declarations]
353 | curl_formadd(&formpost, &lastptr, CURLFORM_COPYNAME, sName.c_str(), CURLFORM_COPYCONTENTS, sValue.c_str(), CURLFORM_END);
| ^~~~~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/curl/curl.h:2504:3: note: declared here
2504 | CURLFORM_COPYCONTENTS CURL_DEPRECATED(7.56.0, "Use curl_mime_data()"),
| ^~~~~~~~~~~~~~~~~~~~~
curl.c:353:18: warning: ‘CURLFORMcode curl_formadd(curl_httppost**, curl_httppost**, ...)’ is deprecated: since 7.56.0. Use curl_mime_init() [-Wdeprecated-declarations]
353 | curl_formadd(&formpost, &lastptr, CURLFORM_COPYNAME, sName.c_str(), CURLFORM_COPYCONTENTS, sValue.c_str(), CURLFORM_END);
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/curl/curl.h:2576:1: note: declared here
2576 | curl_formadd(struct curl_httppost **httppost,
| ^~~~~~~~~~~~
curl.c:363:37: warning: ‘CURLFORM_COPYNAME’ is deprecated: since 7.56.0. Use curl_mime_name() [-Wdeprecated-declarations]
363 | curl_formadd(&formpost, &lastptr, CURLFORM_COPYNAME, sName.c_str(), CURLFORM_COPYCONTENTS, sValue.c_str(), CURLFORM_END);
| ^~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/curl/curl.h:2501:3: note: declared here
2501 | CURLFORM_COPYNAME CURL_DEPRECATED(7.56.0, "Use curl_mime_name()"),
| ^~~~~~~~~~~~~~~~~
curl.c:363:71: warning: ‘CURLFORM_COPYCONTENTS’ is deprecated: since 7.56.0. Use curl_mime_data() [-Wdeprecated-declarations]
363 | curl_formadd(&formpost, &lastptr, CURLFORM_COPYNAME, sName.c_str(), CURLFORM_COPYCONTENTS, sValue.c_str(), CURLFORM_END);
| ^~~~~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/curl/curl.h:2504:3: note: declared here
2504 | CURLFORM_COPYCONTENTS CURL_DEPRECATED(7.56.0, "Use curl_mime_data()"),
| ^~~~~~~~~~~~~~~~~~~~~
curl.c:363:15: warning: ‘CURLFORMcode curl_formadd(curl_httppost**, curl_httppost**, ...)’ is deprecated: since 7.56.0. Use curl_mime_init() [-Wdeprecated-declarations]
363 | curl_formadd(&formpost, &lastptr, CURLFORM_COPYNAME, sName.c_str(), CURLFORM_COPYCONTENTS, sValue.c_str(), CURLFORM_END);
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/curl/curl.h:2576:1: note: declared here
2576 | curl_formadd(struct curl_httppost **httppost,
| ^~~~~~~~~~~~
curl.c:367:16: warning: ‘void curl_formfree(curl_httppost*)’ is deprecated: since 7.56.0. Use curl_mime_free() [-Wdeprecated-declarations]
367 | curl_formfree(formpost);
| ~~~~~~~~~~~~~^~~~~~~~~~
/usr/include/x86_64-linux-gnu/curl/curl.h:2612:1: note: declared here
2612 | curl_formfree(struct curl_httppost *form);
| ^~~~~~~~~~~~~
curl.c: In member function ‘int cCurl::PostRaw(const char*, const std::string&, std::string*, const std::string&)’:
curl.c:386:16: warning: ‘void curl_formfree(curl_httppost*)’ is deprecated: since 7.56.0. Use curl_mime_free() [-Wdeprecated-declarations]
386 | curl_formfree(formpost);
| ~~~~~~~~~~~~~^~~~~~~~~~
/usr/include/x86_64-linux-gnu/curl/curl.h:2612:1: note: declared here
2612 | curl_formfree(struct curl_httppost *form);
| ^~~~~~~~~~~~~
curl.c: In member function ‘int cCurl::DoPost(const char*, std::string*, const std::string&, curl_httppost*, curl_slist*)’:
curl.c:400:29: warning: ‘CURLOPT_HTTPPOST’ is deprecated: since 7.56.0. Use CURLOPT_MIMEPOST [-Wdeprecated-declarations]
400 | curl_easy_setopt(handle, CURLOPT_HTTPPOST, formpost);
| ^~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/curl/curl.h:1190:3: note: declared here
1190 | CURLOPTDEPRECATED(CURLOPT_HTTPPOST, CURLOPTTYPE_OBJECTPOINT, 24,
| ^~~~~~~~~~~~~~~~~
Compile searchtimer ..Pakete epg:
hi epgd 1.3.24+git20240610-2-544018b-0yavdr1~noble+local1
hi epghttpd 1.3.24+git20240610-2-544018b-0yavdr1~noble+local1
hi mariadb-plugin-epglv 1.3.24+git20240610-2-544018b-0yavdr1~noble+local1
hi vdr-epg-daemon 1.3.24+git20240610-2-544018b-0yavdr1~noble+local1
ii vdr-plugin-epg2vdr 1.2.16-0yavdr5~noble
ii vdr-plugin-epgsearch 2.4.2+git20240407-10-bd749fe-0yavdr3~noble Pakete python:
...
ii libpython3-all-dbg:amd64 3.12.3-0ubuntu1
ii libpython3-dbg:amd64 3.12.3-0ubuntu1
ii libpython3-dev:amd64 3.12.3-0ubuntu1
ii libpython3-stdlib:amd64 3.12.3-0ubuntu1
ii libpython3.12-dev:amd64 3.12.3-1
ii libpython3.12-minimal:amd64 3.12.3-1
ii libpython3.12-stdlib:amd64 3.12.3-1
ii libpython3.12-testsuite 3.12.3-1
ii libpython3.12t64:amd64 3.12.3-1
ii libpython3.12t64-dbg:amd64
...
ii python3.12 3.12.3-1
ii python3.12-dbg 3.12.3-1
ii python3.12-dev 3.12.3-1
ii python3.12-full 3.12.3-1
ii python3.12-minimal 3.12.3-1
ii python3.12-venv 3.12.3-1
ii yavdr-frontend-tools 0.0.67-0yavdr1~noble
...Curl:
ii curl 8.5.0-2ubuntu10.1
ii libcurl3t64-gnutls:amd64 8.5.0-2ubuntu10.1
ii libcurl4-openssl-dev:amd64 8.5.0-2ubuntu10.1
ii libcurl4t64:amd64 8.5.0-2ubuntu10.1
ii libcurlpp-dev:amd64 0.8.1-5.3build1
ii libcurlpp0t64:amd64 0.8.1-5.3build1
ii php-curl 2:8.3+93ubuntu2
ii php8.3-curl 8.3.6-0ubuntu0.24.04.1Gruß
Frank
nein mit den Curl Meldungen hat es zu 99,9% nichts zu tun.
Interessant wäre ob es auf diesem System mit einer älteren libpython z.B. der 3.8 auch passiert, ich weiß nicht wann ich dazu kommen eine entsprechende Testumgebung aufzubauen.
und nun ist es die 3.12, wäre interessant ab welcher es nicht mehr geht
Hi horchi,
ich habe Yavdr per Ansible in einer VM installiert (noble).
epgd+httpd+mariadb mit eignen Ansible Rollen.
Die Python-Pakete für 3.10 und 3.11 von hier: PPA
Die Pakete für epgd und epghttpd habe ich mit den Sourcen von yavdr gebaut (1.3.24+git20240610).
3.10 und 3.11 haben funktioniert, bei 3.12 (ubuntu noble) nicht.
Der BT sieht für mich aus wie die anderen.
root@test-epgd:/usr/local/src/epgd/3-12# coredumpctl debug
PID: 81573 (epghttpd)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Tue 2024-07-30 19:23:18 CEST (6s 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: fc2b02e7a65c4886ac51c5c9f9ddd9cc
Machine ID: 146b85d4f08f4d21a93afcdbc705b5b7
Hostname: test-epgd
Storage: /var/lib/systemd/coredump/core.epghttpd.0.fc2b02e7a65c4886ac51c5c9f9ddd9cc.81573.1722360198000000.zst (present)
Size on Disk: 1.3M
Message: Process 81573 (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 81574:
#0 0x000079dc64af78d5 n/a (libpython3.12.so.1.0 + 0x2f78d5)
#1 0x000079dc64a9c936 n/a (libpython3.12.so.1.0 + 0x29c936)
#2 0x000079dc64a9d356 n/a (libpython3.12.so.1.0 + 0x29d356)
#3 0x000079dc64984b76 PyObject_CallObject (libpython3.12.so.1.0 + 0x184b76)
#4 0x0000590bec797742 _ZN6Python7executeEP8cDbTableiPKc (epghttpd + 0x8e742)
#5 0x0000590bec728734 _ZN9cEpgHttpd13storeTimerJobEP6json_tS1_ (epghttpd + 0x1f734)
#6 0x0000590bec741b29 _ZN9cEpgHttpd15performPostDataEPKcP12MemoryStruct (epghttpd + 0x38b29)
#7 0x0000590bec74244f _ZN9cEpgHttpd10dispatcherEPvP14MHD_ConnectionPKcS4_S4_S4_PmPS0_ (epghttpd + 0x3944f)
#8 0x000079dc6523372e n/a (libmicrohttpd.so.12 + 0xb72e)
#9 0x000079dc652361e8 n/a (libmicrohttpd.so.12 + 0xe1e8)
#10 0x000079dc652395e8 n/a (libmicrohttpd.so.12 + 0x115e8)
#11 0x000079dc6523ac61 n/a (libmicrohttpd.so.12 + 0x12c61)
#12 0x000079dc65244035 n/a (libmicrohttpd.so.12 + 0x1c035)
#13 0x000079dc6389ca94 start_thread (libc.so.6 + 0x9ca94)
#14 0x000079dc63929c3c __clone3 (libc.so.6 + 0x129c3c)
Stack trace of thread 81573:
#0 0x000079dc638ecadf __GI___clock_nanosleep (libc.so.6 + 0xecadf)
#1 0x000079dc638f9a27 __GI___nanosleep (libc.so.6 + 0xf9a27)
#2 0x000079dc6390ec63 __sleep (libc.so.6 + 0x10ec63)
#3 0x0000590bec7406c7 _ZN9cEpgHttpd4loopEv (epghttpd + 0x376c7)
#4 0x0000590bec74409a main (epghttpd + 0x3b09a)
#5 0x000079dc6382a1ca __libc_start_call_main (libc.so.6 + 0x2a1ca)
#6 0x000079dc6382a28b __libc_start_main_impl (libc.so.6 + 0x2a28b)
#7 0x0000590bec725085 _start (epghttpd + 0x1c085)
ELF object binary architecture: AMD x86-64Prima, danke für den Test!
Dann gilt es herauszufinden was sich zwischen 3.11 und 3.12 geändert hat.
Ich habe zwar von Python, C, C++ usw. keine Ahnung, bin beim Suchen aber über diese Seite gestolpert.
https://docs.python.org/3/c-api/module.html
Scheinbar wurde mit 3.12 eine neuer Parameter(?) eingeführt der Einfluss auf die Initialisierung von Modulen hat.
Nur habe ich keine Ahnung ob Single- oder Multi-Phase verwendet werden soll.
ZitatIf
Py_mod_multiple_interpretersis not specified, the import machinery defaults toPy_MOD_MULTIPLE_INTERPRETERS_NOT_SUPPORTED.Added in version 3.12.
Vielleicht hilf es ja weiter.
ja bin auch schon auf MULTIPLE_INTERPRETERS gestoßen ich schaue mal was ich da einbauen muss
ich hab mir mal die Hinweise zum Thread handing für die Python Lib angesehen und mal Test weise etwas eingebaut (untested!)
diff --git a/lib/python.c b/lib/python.c
index faf769f..1e78734 100644
--- a/lib/python.c
+++ b/lib/python.c
@@ -215,6 +215,8 @@ Python::~Python()
int Python::init(const char* modulePath)
{
PyObject* pName {};
+ PyGILState_STATE gstate;
+ gstate = PyGILState_Ensure();
tell(eloInfo, "Initialize python script '%s/%s.py'", modulePath, file);
@@ -255,7 +257,7 @@ int Python::init(const char* modulePath)
{
showError();
tell("Failed to load '%s.py'", file);
-
+ PyGILState_Release(gstate);
return fail;
}
@@ -269,15 +271,20 @@ int Python::init(const char* modulePath)
showError();
tell("Cannot find function '%s'", function);
-
+ PyGILState_Release(gstate);
return fail;
}
+ PyGILState_Release(gstate);
+
return success;
}
int Python::exit()
{
+ PyGILState_STATE gstate;
+ gstate = PyGILState_Ensure();
+
usages--;
if (pFunc)
@@ -289,6 +296,8 @@ int Python::exit()
if (!usages)
Py_Finalize();
+ PyGILState_Release(gstate);
+
return success;
}
@@ -300,6 +309,9 @@ int Python::execute(cDbTable* eventsDb, int namingmode, const char* tmplExpressi
{
PyObject* pValue;
+ PyGILState_STATE gstate;
+ gstate = PyGILState_Ensure();
+
free(result);
result = 0;
@@ -311,6 +323,7 @@ int Python::execute(cDbTable* eventsDb, int namingmode, const char* tmplExpressi
if (!pValue)
{
+ PyGILState_Release(gstate);
showError();
tell("Python: Call of function '%s()' failed", function);
@@ -332,6 +345,7 @@ int Python::execute(cDbTable* eventsDb, int namingmode, const char* tmplExpressi
Py_DECREF(pValue);
+ PyGILState_Release(gstate);
return success;
}es compiliert, weiter konnte ich noch nicht testen.
/EDIT: könnt ja mal berichten wenn ihr es damit testen konntet
Mache ich etwas falsch, wenn ich den Patch in eine Datei kopiere und dann im Hauptverzeichnis meiner Quellen ausführe?
vboxuser@test-epgd:/usr/local/src/epgd/vdr-epg-daemon-1.3.24+git20240610-2-544018b-0yavdr1~noble+local$ patch --verbose -p1 < python_gstate.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|diff --git a/lib/python.c b/lib/python.c
|index faf769f..1e78734 100644
|--- a/lib/python.c
|+++ b/lib/python.c
--------------------------
patching file lib/python.c
Using Plan A...
patch: **** malformed patch at line 6: int Python::init(const char* modulePath) horchi , ich habe die VM zurückgesetzt und Deinen Patch manuell eingefügt.
Das Kompilieren läuft ohne Fehler durch, aber jetzt startet epghttpd nicht mehr.
root@test-epgd:~# systemctl status epghttpd.service
● epghttpd.service - epghttpd provides a webinterface for epg data
Loaded: loaded (/usr/lib/systemd/system/epghttpd.service; enabled; preset: enabled)
Active: activating (auto-restart) (Result: core-dump) since Sun 2024-08-11 16:12:31 CEST; 51ms ago
Process: 9366 ExecStart=/usr/bin/epghttpd -n -c /etc/epgd (code=dumped, signal=SEGV)
Main PID: 9366 (code=dumped, signal=SEGV)
CPU: 159ms
Aug 11 16:12:31 test-epgd systemd[1]: epghttpd.service: Main process exited, code=dumped, status=11/SEGV
Aug 11 16:12:31 test-epgd systemd[1]: epghttpd.service: Failed with result 'core-dump'.
Aug 11 16:12:31 test-epgd systemd[1]: Failed to start epghttpd.service - epghttpd provides a webinterface for epg data.Dump
root@test-epgd:~# coredumpctl debug
PID: 8821 (epgd)
UID: 0 (root)
GID: 0 (root)
Signal: 11 (SEGV)
Timestamp: Sun 2024-08-11 16:11:44 CEST (5s ago)
Command Line: /usr/bin/epgd -n
Executable: /usr/bin/epgd
Control Group: /system.slice/epgd.service
Unit: epgd.service
Slice: system.slice
Boot ID: 307b7fd8e98949318ae7a2cfd9174081
Machine ID: 146b85d4f08f4d21a93afcdbc705b5b7
Hostname: test-epgd
Storage: /var/lib/systemd/coredump/core.epgd.0.307b7fd8e98949318ae7a2cfd9174081.8821.1723385504000000.zst (present)
Size on Disk: 690.3K
Message: Process 8821 (epgd) 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 8821:
#0 0x00007395f4af3799 n/a (libpython3.12.so.1.0 + 0x2f3799)
#1 0x00007395f4af5f7d PyGILState_Ensure (libpython3.12.so.1.0 + 0x2f5f7d)
#2 0x0000589e4769489d _ZN6Python4initEPKc (epgd + 0xb089d)
#3 0x0000589e4768a4ce _ZN12cSearchTimer4initEPKc (epgd + 0xa64ce)
#4 0x0000589e476079e3 _ZN5cEpgd4initEv (epgd + 0x239e3)
#5 0x0000589e4760350a main (epgd + 0x1f50a)
#6 0x00007395f382a1ca __libc_start_call_main (libc.so.6 + 0x2a1ca)
#7 0x00007395f382a28b __libc_start_main_impl (libc.so.6 + 0x2a28b)
#8 0x0000589e47602015 _start (epgd + 0x1e015)
ELF object binary architecture: AMD x86-64
GNU gdb (Ubuntu 15.0.50.20240403-0ubuntu1) 15.0.50.20240403-gitversuche es bitte nochmal hiermit.
Ich bekomme damit mit Python 3.8 einen Deadlock und vermute es ist der hier beschriebene. Menie Hoffnung ist das es damit mit der 3.12 läuft
diff --git a/lib/python.c b/lib/python.c
index faf769f..854d0d9 100644
--- a/lib/python.c
+++ b/lib/python.c
@@ -233,6 +233,11 @@ int Python::init(const char* modulePath)
pName = PyString_FromString(file);
#endif
+ PyGILState_STATE gstate;
+ printf("Ensure()\n");
+ gstate = PyGILState_Ensure();
+ printf("Ensure() got\n");
+
usages++;
// add search path for Python modules
@@ -255,7 +260,8 @@ int Python::init(const char* modulePath)
{
showError();
tell("Failed to load '%s.py'", file);
-
+ PyGILState_Release(gstate);
+ printf("Release()\n");
return fail;
}
@@ -269,10 +275,14 @@ int Python::init(const char* modulePath)
showError();
tell("Cannot find function '%s'", function);
-
+ PyGILState_Release(gstate);
+ printf("Release()\n");
return fail;
}
+ PyGILState_Release(gstate);
+ printf("Release()\n");
+
return success;
}
@@ -300,6 +310,11 @@ int Python::execute(cDbTable* eventsDb, int namingmode, const char* tmplExpressi
{
PyObject* pValue;
+ PyGILState_STATE gstate;
+ printf("Ensure()\n");
+ gstate = PyGILState_Ensure();
+ printf("Ensure() got\n");
+
free(result);
result = 0;
@@ -311,6 +326,8 @@ int Python::execute(cDbTable* eventsDb, int namingmode, const char* tmplExpressi
if (!pValue)
{
+ PyGILState_Release(gstate);
+ printf("Release()\n");
showError();
tell("Python: Call of function '%s()' failed", function);
@@ -332,10 +349,12 @@ int Python::execute(cDbTable* eventsDb, int namingmode, const char* tmplExpressi
Py_DECREF(pValue);
+ PyGILState_Release(gstate);
+ printf("Release()\n");
+
return success;
}
-
//***************************************************************************
// Dup Py String
//***************************************************************************Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!