bulletmark
commented
4 years ago Just came to write about a bug and find one already existing - created 3 years ago by me(!).
I have had 3 more of these python core dumps occur over the last couple of months. All running on a different raspberry pi, with a completely different python app, using much later versions but fundamentally the same problem. Here are the details:
pi2b: $ uname -a
Linux pi2b 5.4.42-1-ARCH #1 SMP PREEMPT Tue May 26 01:48:52 UTC 2020 armv7l GNU/Linux
pi2b $ python --version
Python 3.8.3
pi2b: $ venv/bin/pip list
Package Version
---------------- -------
bottle 0.12.18
greenlet 0.4.15
meinheld 1.0.1
pip 20.1
RPi.GPIO 0.7.0
ruamel.yaml 0.16.10
ruamel.yaml.clib 0.2.0
setuptools 41.2.0
timesched 1.5
wccontrol 1.13
wheel 0.34.2
pi2b: $gdb ./venv/bin/python ~/core.dump
GNU gdb (GDB) 9.2
Copyright (C) 2020 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 "armv7l-unknown-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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 ./venv/bin/python...
(No debugging symbols found in ./venv/bin/python)
[New LWP 330]
[New LWP 340]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `venv/bin/python -u /home/pi/Data/src/wcscheduler/wcscheduler'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x756c5138 in import_greenlet () at meinheld/server/greensupport.c:14
14 meinheld/server/greensupport.c: No such file or directory.
[Current thread is 1 (Thread 0x76f57010 (LWP 330))]
(gdb) where
#0 0x756c5138 in import_greenlet () at meinheld/server/greensupport.c:14
#1 import_greenlet () at meinheld/server/greensupport.c:11
#2 greenlet_new (o=0x74fae460, parent=0x0) at meinheld/server/greensupport.c:31
#3 0x756b7640 in call_wsgi_handler (client=<optimized out>) at meinheld/server/server.c:717
#4 0x756bc1b8 in accept_callback (loop=0x135b950, fd=4, events=<optimized out>, cb_arg=<optimized out>)
at meinheld/server/server.c:1274
#5 0x756c5ff8 in picoev_poll_once_internal (_loop=_loop@entry=0x135b950, max_wait=<optimized out>)
at meinheld/server/picoev_epoll.c:173
#6 0x756bb30c in picoev_loop_once (max_wait=<optimized out>, loop=0x135b950)
at meinheld/server/picoev.h:390
#7 meinheld_run_loop (self=<optimized out>, args=<optimized out>, kwds=<optimized out>)
at meinheld/server/server.c:1857
#8 0x76c939c8 in ?? () from /usr/lib/libpython3.8.so.1.0
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
My Python 3 app core dumped yesterday on a Raspberry Pi 2 running Arch Arm. Versions and coredump details are below.
Occurred after updating system and rebooting but unfortunately I can not repeat the crash so seems just a one-off atm. I am raising this issue so it is known about. This app has been running for many years although I frequently update system and PyPI packages though.