SUMMARY pykig.py was recently ported to python3. However it now aborts with a failing assertion related to a malloc STEPS TO REPRODUCE 1. Create a simple pykig.py script. It can be as simple as the creation of a point: ---- sample.kpy: sample pykig.py file ---- Point (1,1) ---- end sample ---- or even an empty file will do 2. Execute it: pykig.py sample.kpy OBSERVED RESULT On the console the following fatal error is printed: python3: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Aborted (core dumped) EXPECTED RESULT kig should be opened with a point shown at coordinates (1,1) SOFTWARE/OS VERSIONS KDE Plasma Version: 5.16.5 KDE Frameworks Version: kf5 Qt Version: qt5 5.12.5 ADDITIONAL INFORMATION The sample file above works well with a version of pykig.py prior to the port to python3
Created attachment 124916 [details] a sample kpy external script to test agains this bug report This is just a sample file. Even an empty file should demonstrate the bug
Works fine here. Is your kig compiled with python 3?
Resolved (almost)! in a Fedora environment in order to make the *internal* python scripting to work with mathematical functions it is required to first define LD_PRELOAD to point to the libpython library. It turns out that a working (for me at least) definition still requires python2: export LD_PRELOAD=/usr/lib64/libpython2.7.so.1.0 however this turns out to be *incompatible* with the present state of pykig.py, leading to the failing assertion stated in my original bug report. A workaround is then (at least in a Fedora environment) the followint: $ export LD_PRELOAD= $ pykig.py -o sample.kig sample.kpy $ export LD_PRELOAD=/usr/lib64/libpython2.7.so.1.0 $ kig sample.kig of course, if the construction in sample.kpy does not require internal python scripting or if the internal python scripting does not make use of mathematical functions, then this would not be required.
(In reply to Antonio Rojas from comment #2) > Works fine here. Is your kig compiled with python 3? This is an interesting question: I *thought* my kig was compiled with python3, What I have now installed is the result with the latest git HEAD in a Fedora 31 updated box. an 'ldd /usr/bin/kig' does not show any reference to python libraries
(In reply to Maurizio Paolini from comment #4) > (In reply to Antonio Rojas from comment #2) > > Works fine here. Is your kig compiled with python 3? > > This is an interesting question: I *thought* my kig was compiled with > python3, > What I have now installed is the result with the latest git HEAD in a Fedora > 31 updated box. > an 'ldd /usr/bin/kig' does not show any reference to python libraries You need to look at ldd output for kigpart.so, the kig binary itself doesn't link to python
LD_PRELOADing Python 2 into the current Fedora kig is definitely not supported. If you have to do that, something is very wrong.
(In reply to Kevin Kofler from comment #6) > LD_PRELOADing Python 2 into the current Fedora kig is definitely not > supported. If you have to do that, something is very wrong. Actually at the moment I have kig compiled from latest git sources. This is because of the recent struggle for the "assert" problem (https://bugs.kde.org/show_bug.cgi?id=415918). I will test everything against the latest 'rpm' of kig in a moment.
(In reply to Kevin Kofler from comment #6) > LD_PRELOADing Python 2 into the current Fedora kig is definitely not > supported. If you have to do that, something is very wrong. It is because of #335965, I think.
(In reply to Antonio Rojas from comment #5) > (In reply to Maurizio Paolini from comment #4) > > (In reply to Antonio Rojas from comment #2) > > > Works fine here. Is your kig compiled with python 3? > > > > This is an interesting question: I *thought* my kig was compiled with > > python3, > > What I have now installed is the result with the latest git HEAD in a Fedora > > 31 updated box. > > an 'ldd /usr/bin/kig' does not show any reference to python libraries > > You need to look at ldd output for kigpart.so, the kig binary itself doesn't > link to python ok, I ran " ldd /usr/lib64/qt5/plugins/kigpart.so | grep python" and got libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f2d91c44000) libboost_python27.so.1.69.0 => /lib64/libboost_python27.so.1.69.0 (0x00007f2d91c00000) (After a "git pull; make; make install" of the kig project). I do not know if this is the result of a messy situation: I actually loss control of the status of the transition to python2.7. I just tried to recompile from scratch and the output of cmake produces: [...] -- Found BoostPython: /usr/lib64/libpython2.7.so;/usr/lib64/libboost_python.so [...] so I guess that there is some reminiscence of python2
I had a symbolic link to /usr/lib64/libpython2* instead of the (presumably correct) version 3. I guess this is a leftover of my recent bug-chasing effort... so now I recompiled from scratch and it seems that now everything is fine. I still need the "export LD_PRELOAD=/usr/lib64/libpython3.7m.so.1.0" though, even if I do not use any math function in the python script.
The Fedora package has this patch: https://src.fedoraproject.org/rpms/kig/blob/master/f/0001-explicitly-use-QLibrary-to-load-libpython-like-pykde.patch for bug #335965.
Should the Plasma platform plugin call QIconLoader::updateSystemTheme()?
Oops, sorry, I commented into the wrong bug, please disregard that last comment.
(In reply to Kevin Kofler from comment #11) > The Fedora package has this patch: > https://src.fedoraproject.org/rpms/kig/blob/master/f/0001-explicitly-use- > QLibrary-to-load-libpython-like-pykde.patch > for bug #335965. Right. Actually bug #335965 just got into the way and confused me somewhat. Now everything is fine. Thank you (David and Kevin) for helping me out and sorry for opening a nonexistent bug!
(In reply to Kevin Kofler from comment #11) > The Fedora package has this patch: > https://src.fedoraproject.org/rpms/kig/blob/master/f/0001-explicitly-use- > QLibrary-to-load-libpython-like-pykde.patch > for bug #335965. Update: after cleaning up things properly on my box it turns out that the "export LD_PRELOAD=..." workaround is no longer necessary, so that the mentioned patch seems no longer required! It seems that this is related to the transition from python2 to python3.