I'm having trouble running canorus 0.7.3rc3 on Arch Linux. (Though Arch is a less widespread distribution it has become more popular now thanks to Manjaro and Antergos, as well as word of mouth. Hopefully this is not an esoteric, Arch-specific issue.)
There is an official Arch package for canorus under the community repository. I installed this package but it crashes upon start-up. Please see this Flyspray bug report URL:
I guess I should also file a bug ticket here but I've searched and haven't found others with canorus crashing problems. IMHO this almost certainly has to be caused by the new Python version -- right? Is the python-3.7.patch Arch uses bad somehow? Has anyone else tried building against Python 3.7?
TIA.
Clemmitt Sigler
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The runtime error is weird indeed. We have added support for python3.x just
recently. Maybe Štefan could take a look whether it's an issue with the new
python or arch-specific? Can you enable debugging symbols and provide us
with the backtrace of the crash (uncomment SET(CMAKE_BUILD_TYPE "Debug") in
8th line in CMakeLists.txt).
In any case, you can always compile Canorus without python support: cmake
-DNO_PYTHON=1 . This should fix your crash, but of course disables the
support for python plugins.
I'm having trouble running canorus 0.7.3rc3 on Arch Linux. (Though Arch
is a less widespread distribution it has become more popular now thanks to
Manjaro and Antergos, as well as word of mouth. Hopefully this is not an
esoteric, Arch-specific issue.)
There is an official Arch package for canorus under the community
repository. I installed this package but it crashes upon start-up. Please
see this Flyspray bug report URL:
I guess I should also file a bug ticket here but I've searched and haven't
found others with canorus crashing problems. IMHO this almost certainly
has to be caused by the new Python version -- right? Is the
python-3.7.patch Arch uses bad somehow? Has anyone else tried building
against Python 3.7?
1.) Indeed, "cmake -DNO_PYTHON=1" eliminates the start-up crash.
2.) I think I succeeded (by sidestepping Arch's package build system) in building canorus with debugging symbols enabled. Here's the gdb output:
[]
$ gdb ./install/bin/canorus
GNU gdb (GDB) 8.1.1
Copyright (C) 2018 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: 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 ./install/bin/canorus...done.
(gdb) run
Starting program: /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/install/bin/canorus [Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0x7fffdc80f700 (LWP 30823)] [New Thread 0x7fffd3fbf700 (LWP 30824)] [New Thread 0x7fffd37be700 (LWP 30825)] [New Thread 0x7fffd1322700 (LWP 30826)] [New Thread 0x7fffd0835700 (LWP 30827)] [New Thread 0x7fffc2d23700 (LWP 30829)] [New Thread 0x7fffc1cdd700 (LWP 30830)] [New Thread 0x7fffc14dc700 (LWP 30831)] [New Thread 0x7fffc0cdb700 (LWP 30833)] [New Thread 0x7fffabfff700 (LWP 30834)] [New Thread 0x7fffab7fe700 (LWP 30835)]
Fatal Python error: PyEval_AcquireThread: NULL new thread state
Current thread 0x00007fffdf068fc0 (most recent call first):
Thread 1 "canorus" received signal SIGABRT, Aborted.
0x00007fffeeadfd7f in raise () from /usr/lib/libc.so.6
(gdb) where
#0 0x00007fffeeadfd7f in raise () at /usr/lib/libc.so.6
#1 0x00007fffeeaca672 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff77a9672 in () at /usr/lib/libpython3.7m.so.1.0
#3 0x00007ffff77a968a in PyGrammar_LabelRepr ()
at /usr/lib/libpython3.7m.so.1.0
#4 0x00007ffff77ab11f in () at /usr/lib/libpython3.7m.so.1.0
#5 0x000055555560fcad in CASwigPython::init() ()
at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/scripting/swigpython.cpp:85
#6 0x00005555555a3256 in CACanorus::initScripting() ()
at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canorus.cpp:181
#7 0x000055555559fd32 in main(int, char**) (argc=1, argv=0x7fffffffe4f8)
at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/main.cpp:82
[]
(Please excuse the '\' characters above which keep formatting of the post sane.)
So this crash IS caused by the Arch AUR's python-3.7.patch which introduces the statement "PyEval_AcquireThread(state);". This triggers the crash. So the deprecation by Python 3.7 of functions like PyEval_AcquireLock() -- which was replaced via this patch -- is the proximate cause.
Thank you again for helping me get a start at debugging. I'll post this information on the Arch Linux bug report.
Cheers!
Clemmitt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The executable still crashes -- here is a stack traceback from gdb:
- * - * - * - [New LWP 838] [New LWP 839] [New LWP 843] [New LWP 842] [New LWP 851] [New LWP 840] [New LWP 841] [Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `./src/canorus'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fd7fca83f48 in PyErr_Restore () from /usr/lib/libpython3.7m.so.1.0 [Current thread is 1 (Thread 0x7fd7e42c2fc0 (LWP 838))]
#0 0x00007fd7fca83f48 in PyErr_Restore () at /usr/lib/libpython3.7m.so.1.0
#1 0x00007fd7fcaa17b6 in PyDict_GetItem () at /usr/lib/libpython3.7m.so.1.0
#2 0x00007fd7fca9fe98 in PyType_Ready () at /usr/lib/libpython3.7m.so.1.0
#3 0x00005616ca09cd6d in SwigPyObject_TypeOnce() () at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:2012
#4 0x00005616ca09c63f in SwigPyObject_type() () at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:1673
#5 0x00005616ca09cdc1 in SwigPyObject_New(void, swig_type_info, int) (ptr=0x5616ccc2a220, ty=0x5616ca1f90e0 <_swigtp_CAPyConsoleInterface>, own=0) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:2022
#6 0x00005616ca09e1a9 in SWIG_Python_NewPointerObj(PyObject, void, swig_type_info*, int) (self=0x0, ptr=0x5616ccc2a220, type=0x5616ca1f90e0 <_swigtp_CAPyConsoleInterface>, flags=0) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:2664
#7 0x00005616ca0a0100 in CASwigPython::toPythonObject(void, CASwigPython::CAClassType) (object=0x5616ccc2a220, type=CASwigPython::PyConsoleInterface) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:3973
#8 0x00005616c9ff8c0f in CAPlugin::callAction(CAPluginAction, CAMainWin, CADocument, QEvent, QPoint, QString) (this=0x5616cc2038c0, action=0x5616ccb313d0, mainWin=0x5616cc9cef00, document=0x0, evt=0x0, coords=0x0, filename=...) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/interface/plugin.cpp:238
#9 0x00005616c9ff84f8 in CAPlugin::action(QString, CAMainWin, CADocument, QEvent, QPoint) (this=0x5616cc2038c0, onAction=..., mainWin=0x5616cc9cef00, document=0x0, evt=0x0, coords=0x0) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/interface/plugin.cpp:76
#10 0x00005616c9ff09d5 in CAPluginManager::enablePlugin(CAPlugin, CAMainWin) (plugin=0x5616cc2038c0, mainWin=0x5616cc9cef00) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/interface/pluginmanager.cpp:179
#11 0x00005616c9ff06e8 in CAPluginManager::enablePlugins(CAMainWin) (mainWin=0x5616cc9cef00) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/interface/pluginmanager.cpp:125
#12 0x00005616c9f6918d in CAMainWin::CAMainWin(QMainWindow) (this=0x5616cc9cef00, oParent=0x0) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/ui/mainwin.cpp:176
#13 0x00005616c9ecb9f5 in main(int, char**) (argc=1, argv=0x7ffc4bfe89f8) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/main.cpp:121
- * - * - * -
The problem is PyEval_AcquireLock() and PyEval_ReleaseLock() are now deprecated. Both PyEval_AcquireThread() and PyEval_ReleaseThread() require a PyThreadState *tstate thread state argument and it's not always obvious which one this should be.
I'm sure I just don't understand the structure and use of threads in the python interpreter code. There aren't any in-line comments to explain so I'm kind of banging away in the dark at this.
I do hope this helps. Does someone grok this use of threading? TIA.
Clemmitt
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all,
I'm having trouble running canorus 0.7.3rc3 on Arch Linux. (Though Arch is a less widespread distribution it has become more popular now thanks to Manjaro and Antergos, as well as word of mouth. Hopefully this is not an esoteric, Arch-specific issue.)
There is an official Arch package for canorus under the community repository. I installed this package but it crashes upon start-up. Please see this Flyspray bug report URL:
https://bugs.archlinux.org/task/59760
The PKGBUILD script and a patch to compile against Python 3.7 are located at this URL:
https://git.archlinux.org/svntogit/community.git/tree/trunk?h=packages/canorus
I guess I should also file a bug ticket here but I've searched and haven't found others with canorus crashing problems. IMHO this almost certainly has to be caused by the new Python version -- right? Is the python-3.7.patch Arch uses bad somehow? Has anyone else tried building against Python 3.7?
TIA.
Clemmitt Sigler
Hi Clemmitt.
The runtime error is weird indeed. We have added support for python3.x just
recently. Maybe Štefan could take a look whether it's an issue with the new
python or arch-specific? Can you enable debugging symbols and provide us
with the backtrace of the crash (uncomment SET(CMAKE_BUILD_TYPE "Debug") in
8th line in CMakeLists.txt).
In any case, you can always compile Canorus without python support: cmake
-DNO_PYTHON=1 . This should fix your crash, but of course disables the
support for python plugins.
Regards.
-Matevž
V V tor., 28. avg. 2018 ob 18:26 je oseba Clemmitt Sigler cmsigler@users.sourceforge.net napisala:
Hello, Matevž,
Thank you for kindly buying me two clues :)
1.) Indeed, "cmake -DNO_PYTHON=1" eliminates the start-up crash.
2.) I think I succeeded (by sidestepping Arch's package build system) in building canorus with debugging symbols enabled. Here's the gdb output:
[]
$ gdb ./install/bin/canorus
GNU gdb (GDB) 8.1.1
Copyright (C) 2018 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:
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 ./install/bin/canorus...done.
(gdb) run
Starting program: /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/install/bin/canorus
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffdc80f700 (LWP 30823)]
[New Thread 0x7fffd3fbf700 (LWP 30824)]
[New Thread 0x7fffd37be700 (LWP 30825)]
[New Thread 0x7fffd1322700 (LWP 30826)]
[New Thread 0x7fffd0835700 (LWP 30827)]
[New Thread 0x7fffc2d23700 (LWP 30829)]
[New Thread 0x7fffc1cdd700 (LWP 30830)]
[New Thread 0x7fffc14dc700 (LWP 30831)]
[New Thread 0x7fffc0cdb700 (LWP 30833)]
[New Thread 0x7fffabfff700 (LWP 30834)]
[New Thread 0x7fffab7fe700 (LWP 30835)]
Fatal Python error: PyEval_AcquireThread: NULL new thread state
Current thread 0x00007fffdf068fc0 (most recent call first):
Thread 1 "canorus" received signal SIGABRT, Aborted.
0x00007fffeeadfd7f in raise () from /usr/lib/libc.so.6
(gdb) where
#0 0x00007fffeeadfd7f in raise () at /usr/lib/libc.so.6
#1 0x00007fffeeaca672 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff77a9672 in () at /usr/lib/libpython3.7m.so.1.0
#3 0x00007ffff77a968a in PyGrammar_LabelRepr ()
at /usr/lib/libpython3.7m.so.1.0
#4 0x00007ffff77ab11f in () at /usr/lib/libpython3.7m.so.1.0
#5 0x000055555560fcad in CASwigPython::init() ()
at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/scripting/swigpython.cpp:85
#6 0x00005555555a3256 in CACanorus::initScripting() ()
at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canorus.cpp:181
#7 0x000055555559fd32 in main(int, char**) (argc=1, argv=0x7fffffffe4f8)
at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/main.cpp:82
[]
(Please excuse the '\' characters above which keep formatting of the post sane.)
So this crash IS caused by the Arch AUR's python-3.7.patch which introduces the statement "PyEval_AcquireThread(state);". This triggers the crash. So the deprecation by Python 3.7 of functions like PyEval_AcquireLock() -- which was replaced via this patch -- is the proximate cause.
Thank you again for helping me get a start at debugging. I'll post this information on the Arch Linux bug report.
Cheers!
Clemmitt
Hello again,
I've made a small amount of progress on getting canorus working with Python 3.7. I posted a work-in-progress patch on pastebin:
https://pastebin.com/FEyz6cJU
Also see this Arch Linux Flyspray bug report:
https://bugs.archlinux.org/task/59760
The executable still crashes -- here is a stack traceback from gdb:
- * - * - * -
[New LWP 838]
[New LWP 839]
[New LWP 843]
[New LWP 842]
[New LWP 851]
[New LWP 840]
[New LWP 841]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `./src/canorus'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fd7fca83f48 in PyErr_Restore () from /usr/lib/libpython3.7m.so.1.0
[Current thread is 1 (Thread 0x7fd7e42c2fc0 (LWP 838))]
#0 0x00007fd7fca83f48 in PyErr_Restore () at /usr/lib/libpython3.7m.so.1.0
#1 0x00007fd7fcaa17b6 in PyDict_GetItem () at /usr/lib/libpython3.7m.so.1.0
#2 0x00007fd7fca9fe98 in PyType_Ready () at /usr/lib/libpython3.7m.so.1.0
#3 0x00005616ca09cd6d in SwigPyObject_TypeOnce() () at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:2012
#4 0x00005616ca09c63f in SwigPyObject_type() () at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:1673
#5 0x00005616ca09cdc1 in SwigPyObject_New(void, swig_type_info, int) (ptr=0x5616ccc2a220, ty=0x5616ca1f90e0 <_swigtp_CAPyConsoleInterface>, own=0) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:2022
#6 0x00005616ca09e1a9 in SWIG_Python_NewPointerObj(PyObject, void, swig_type_info*, int) (self=0x0, ptr=0x5616ccc2a220, type=0x5616ca1f90e0 <_swigtp_CAPyConsoleInterface>, flags=0) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:2664
#7 0x00005616ca0a0100 in CASwigPython::toPythonObject(void, CASwigPython::CAClassType) (object=0x5616ccc2a220, type=CASwigPython::PyConsoleInterface) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/canoruspythonPYTHON_wrap.cxx:3973
#8 0x00005616c9ff8c0f in CAPlugin::callAction(CAPluginAction, CAMainWin, CADocument, QEvent, QPoint, QString) (this=0x5616cc2038c0, action=0x5616ccb313d0, mainWin=0x5616cc9cef00, document=0x0, evt=0x0, coords=0x0, filename=...) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/interface/plugin.cpp:238
#9 0x00005616c9ff84f8 in CAPlugin::action(QString, CAMainWin, CADocument, QEvent, QPoint) (this=0x5616cc2038c0, onAction=..., mainWin=0x5616cc9cef00, document=0x0, evt=0x0, coords=0x0) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/interface/plugin.cpp:76
#10 0x00005616c9ff09d5 in CAPluginManager::enablePlugin(CAPlugin, CAMainWin) (plugin=0x5616cc2038c0, mainWin=0x5616cc9cef00) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/interface/pluginmanager.cpp:179
#11 0x00005616c9ff06e8 in CAPluginManager::enablePlugins(CAMainWin) (mainWin=0x5616cc9cef00) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/interface/pluginmanager.cpp:125
#12 0x00005616c9f6918d in CAMainWin::CAMainWin(QMainWindow) (this=0x5616cc9cef00, oParent=0x0) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/ui/mainwin.cpp:176
#13 0x00005616c9ecb9f5 in main(int, char**) (argc=1, argv=0x7ffc4bfe89f8) at /home/siglercm/AUR/multimedia_audio/canorus/canorus-svn/src/trunk/src/main.cpp:121
- * - * - * -
The problem is PyEval_AcquireLock() and PyEval_ReleaseLock() are now deprecated. Both PyEval_AcquireThread() and PyEval_ReleaseThread() require a PyThreadState *tstate thread state argument and it's not always obvious which one this should be.
I'm sure I just don't understand the structure and use of threads in the python interpreter code. There aren't any in-line comments to explain so I'm kind of banging away in the dark at this.
I do hope this helps. Does someone grok this use of threading? TIA.
Clemmitt