Description of problem: My box is a fully updated fedora 27. I need to install kig from the Git tree. Cmake correctly finds the optional python scripting extension and it compiles with no problem. However when trying to enter a python script with one argument kig crashes with the message: kig: /usr/include/boost/python/object_core.hpp:425: boost::python::api::object_base::~object_base(): Assertion `Py_REFCNT(m_ptr) > 0' failed. Additional info: I filed this bug upstream, but it could not be reproduced there. It could be some specific problem in a fedora setting (boost-python?) https://bugs.kde.org/show_bug.cgi?id=388241
It's an upstream bug, they just refuse to fix it :( See https://bugs.kde.org/335965 We carry a patch to fix it in our packaging, https://git.reviewboard.kde.org/r/126549/ *** This bug has been marked as a duplicate of bug 1238113 ***
(In reply to Rex Dieter from comment #1) > It's an upstream bug, they just refuse to fix it :( > > See https://bugs.kde.org/335965 > > We carry a patch to fix it in our packaging, > https://git.reviewboard.kde.org/r/126549/ > > *** This bug has been marked as a duplicate of bug 1238113 *** Sorry Rex, but this is a different problem. I tried to compile from git master after applying the patch in https://git.reviewboard.kde.org/r/126549/ but to no avail: $ kig sin.kig [...] kig: /usr/include/boost/python/object_core.hpp:425: boost::python::api::object_base::~object_base(): Assertion `Py_REFCNT(m_ptr) > 0' failed. Aborted (core dumped) and it not either a Math problem, the crash happens as soon as you define *any* python script having at least one object as argument.
my apologies, re-opening
Can either of you provide a reproducer python script?
Created attachment 1375036 [details] kig file reproducing the problem This kig save file works fine in kig-17.08.1-1.fc27.i686 in an updated fedora 27. It contains a script that simply returns the x coordinate of a point (as a numeric label). It causes a crash when I "make install" kig from the latest "git master" (also in a fedora 27 box)
Created an attachment that causes kig to crash on my box when installed from git master sources. This is the error messages that appears in the konsole: kig: /usr/include/boost/python/object_core.hpp:425: boost::python::api::object_base::~object_base(): Assertion `Py_REFCNT(m_ptr) > 0' failed. Aborted (core dumped)
To help in debugging the problem I tried to run kig with the proposed attachment after compiling from git source on machines with different fedora installations and architectures, with the following results: i686, f27 (3 different boxes): FAIL i686, f26 (1 box): FAIL x86_64, f25: OK x86_64, f24: OK unfortunately I cannot find an x86_64 with f26 nor an i386 with f25 right now.
The assert that fails appeared in boost-1.63 (in fedora 26) and is not present in boost-1.60 (fedora 25). So I came out with the following workaround: 1. download boost sources (version 1.64: fedora 27). Apply the patch: ----------------------------------------------------------------------- --- boost/python/object_core.hpp.assert 2018-01-08 11:22:20.619749851 +0100 +++ boost/python/object_core.hpp 2018-01-08 11:22:34.535582174 +0100 @@ -422,7 +422,7 @@ inline api::object_base& api::object_bas inline api::object_base::~object_base() { - assert( Py_REFCNT(m_ptr) > 0 ); + // assert( Py_REFCNT(m_ptr) > 0 ); Py_DECREF(m_ptr); } ----------------------------------------------------------------------- that removes the assert, and build new rpms. 2. replace all installed boost-* packages and replace with new ones (arguably only the "devel" is perhaps enough) 3. recompile kig from Git sources from scratch ====================================================== Of course this is not a solution: - why was the "assert" added in boost? - why is this not a problem for kig if installed as a fedora package?
The situation appears somewhat creepy: I tried the following, manually edited file /usr/include/boost/python/object_core.hpp applying the following patch: ---------------------------------------------------------------------------- --- object_core.hpp.orig 2017-12-07 15:58:22.000000000 +0100 +++ object_core.hpp 2018-01-10 18:30:29.272278585 +0100 @@ -422,8 +422,10 @@ inline api::object_base::~object_base() { + printf (" Py_REFCNT(m_ptr): %d -> ", Py_REFCNT(m_ptr)); assert( Py_REFCNT(m_ptr) > 0 ); Py_DECREF(m_ptr); + printf ("%d\n", Py_REFCNT(m_ptr)); } inline object::object(detail::borrowed_reference p) ---------------------------------------------------------------------------- [this file is included by kig/scripting/python_scripter.cc and contains the assert that fails when kig is compiled from git sources] Then I downloaded kig-17.08.1-1.fc27.src.rpm, installed it and ran rpmbuild -ba SPEC/kig.spec (*) Then I installed the resulting kig-17.08.1-1.fc27.rpm and ran kig with my test kig file, which opens fine and I immediately close using the 'x' button in the title bar. The resulting text in the konsole terminal is the following: --------------------------------------------------------------- $ kig scripting_bug.kig [...] Py_REFCNT(m_ptr): 4 -> 3 [... 253 similar lines removed that appear ok ...] Py_REFCNT(m_ptr): 1 -> 0 Py_REFCNT(m_ptr): 3 -> 2 Py_REFCNT(m_ptr): 1 -> 0 Py_REFCNT(m_ptr): 2 -> 1 Py_REFCNT(m_ptr): 3 -> 2 Py_REFCNT(m_ptr): 2 -> 1 Py_REFCNT(m_ptr): 0 -> -1 Py_REFCNT(m_ptr): 2 -> 1 Py_REFCNT(m_ptr): 1 -> -1400209280 Py_REFCNT(m_ptr): 3 -> 2 Py_REFCNT(m_ptr): 1 -> 0 Py_REFCNT(m_ptr): 2 -> 1 Py_REFCNT(m_ptr): 3 -> 2 Py_REFCNT(m_ptr): 2 -> 1 Py_REFCNT(m_ptr): 0 -> -1 Py_REFCNT(m_ptr): 2 -> 1 Py_REFCNT(m_ptr): 1 -> 0 Py_REFCNT(m_ptr): 5125 -> 5124 --------------------------------------------------------------- From which I gather that 1. For some reason the "assert" is *not* honored. This is understantable, but confusing when debugging; perhaps at least a terminal message stating that an assert failed would be much better 2. The line Py_REFCNT(m_ptr): 1 -> -1400209280 suggests that there is something going very wrong concerning allocated memory; also the last line is a bit strange. (*) for this see https://bugzilla.redhat.com/show_bug.cgi?id=1532930
for item 1, rpm default build flags in this context include -DNDEBUG which disables asserts
(or at least the behavior is different, my analysis may not be 100% accurate)
Possibly, problem 2 is just a consequence of the previous "destructor" in a situation that *would* cause a failing "assert", which makes sense and moves the problem to why there is a call to a destructor in a situation where the reference count became zero. This is probably a problem to be addressed upstream in "bugs.kde.org", I guess
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The situation is unchanged for a Fedora 29, with boost-devel-1.66.0-14.fc29.x86_64 and compiling kig from the latest Git sources. Now the point is: This is clearly an upstream problem... only it is not clear to me if this is a kig problem or a boost problem. Understanding this requires quite a bit of debugging. Moreover, upstreams, when it comes to kde I do not find much support, often there is no answer to bug reports, sadly.
IMHO, start with documenting the issue with kde upstream with a bug. If that hasn't happened yet, please do so. We're likely not going to be able to fix this ourselves without their assistance.
Filed a bug report upstream. The reference is https://bugs.kde.org/show_bug.cgi?id=401512
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.