On opening cvpcb there's many (408) backtraces, bypassing them does allow cvpcb to work, but closing it crashes kicad. This seems similar to several other reported crashes, but this machine is straight testing. A full log from one of the backtraces is below, all are the same basic erorr just for different classes. ASSERT INFO: ../src/common/object.cpp(251): assert "classTable->Get(m_className) == NULL" failed in Register(): Class "wxCommandEvent" already in RTTI table - have you used IMPLEMENT_DYNAMIC_CLASS() multiple times or linked some object file twice)? BACKTRACE: [1] wxClassInfo::Register() [2] _dl_catch_exception [3] _dl_catch_exception [4] _dl_catch_error [5] dlopen [6] _PyImport_GetDynLoadFunc [7] _PyImport_LoadDynamicModule [8] PyImport_ImportModuleLevel [9] PyObject_Call [10] PyEval_CallObjectWithKeywords [11] PyEval_EvalFrameEx [12] PyEval_EvalCodeEx [13] PyEval_EvalCode [14] PyImport_ExecCodeModuleEx [15] PyImport_ImportModuleLevel [16] PyObject_Call [17] PyEval_CallObjectWithKeywords [18] PyEval_EvalFrameEx [19] PyEval_EvalCodeEx [20] PyEval_EvalCode [21] PyImport_ExecCodeModuleEx [22] PyImport_ImportModuleLevel [23] PyObject_Call [24] PyEval_CallObjectWithKeywords [25] PyEval_EvalFrameEx [26] PyEval_EvalCodeEx [27] PyEval_EvalCode [28] PyImport_ExecCodeModuleEx [29] PyImport_ImportModuleLevel [30] PyObject_Call [31] PyEval_CallObjectWithKeywords [32] PyEval_EvalFrameEx [33] PyEval_EvalCodeEx [34] PyEval_EvalCode [35] PyImport_ExecCodeModuleEx [36] PyImport_ImportModuleLevel [37] PyEval_EvalFrameEx [38] PyEval_EvalFrameEx [39] PyEval_EvalCodeEx [40] PyEval_EvalFrameEx [41] PyEval_EvalCodeEx [42] PyEval_EvalCode [43] PyRun_StringFlags [44] PyRun_SimpleStringFlags [45] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) [46] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) [47] wxEvtHandler::TryHereOnly(wxEvent&) [48] wxEvtHandler::ProcessEventLocally(wxEvent&) [49] wxEvtHandler::ProcessEvent(wxEvent&) [50] wxEvtHandler::ProcessPendingEvents() [51] wxAppConsoleBase::ProcessPendingEvents() [52] wxApp::DoIdle() [53] g_main_context_dispatch [54] g_main_loop_run [55] gtk_main [56] wxGUIEventLoop::DoRun() [57] wxEventLoopBase::Run() [58] wxAppConsoleBase::MainLoop() [59] wxEntry(int&, wchar_t**) [60] __libc_start_main [61] _start
Hello Seth, seems there is another issue with the RTTI implementation, now as far I see on amd64. Maybe this is already fixed in the current HEAD of the 5.x tree? You will need a DGB log? Am 16.11.18 um 05:18 schrieb Julien Goodwin:
Hello Carsten- Am 2018-11-16 02:00, schrieb Carsten Schoenert: As I recall, this issue is an incompatibility between 3.0.2 and 3.0.4 of the wx libraries. If Julien downgrades libwxbase and libwxgtk3.0 to the 3.0.2.0+dfsg-8, this issue should go away. Please let me know if it doesn't.
Am 16.11.18 um 15:28 schrieb Seth Hillbrand: Just for the record, testing/unstable is providing 3.0.4+dfsg-4 and stable/stretch is providing 3.0.2+dfsg-4, backports hold the same version as testing. So downgrading is a bit difficult and right now before the soft freeze for Buster not the right way I think. I can try to build some recent version of 5.x for experimental. But currently don't know if I will will find to do this in the next days.
Am 2018-11-16 12:39, schrieb Carsten Schoenert: That's a fair assessment. I believe the issue is mixing versions. So an alternate solution is to upgrade both to the 3.0.4 version. I would be curious to hear if there were issues when both are running on 3.0.4 as I haven't had any issues in Buster related to this.
It looks to me like the python-wxgtk and wxwidgets versioning is orthogonal, it's just chance they happen to be similar. I did try doing a rebuild of the python-wxgtk source package (on my affected machine) to see if that would help, and it's the same behaviour. One thing I forgot to mention, this also affected the last build of 5.0, before 5.0.1.
Hi Julien- Am 2018-11-16 22:37, schrieb Julien Goodwin: My apologies for the hasty response the first time. I gave a poor response. python-wxgtk3.0=3.0.2.0+dfsg-7 and higher are compiled against gtk3.0. This conflicts with the GTK2.0 versions of wxgtk3.0 that KiCad 5 is compiled against. The latest version that can be used is python-wxgtk3.0=3.0.2.0+dfsg-6. You will need to downgrade this package. Best- Seth
Hello Seth, Am 17.11.18 um 05:34 schrieb Seth Hillbrand: now I'm really confused. I added a versioned dependency on python-wxgtk3.0 >= 3.0.2.0+dfsg-7~ to the kicad package on Apr 8 2018 in preparation for 5.0.0_rc1+dfsg1+20180318-3. https://salsa.debian.org/electronics-team/KiCad/kicad/commit/35b932c4ad0ef184d18f1d72ca81fef6c21dc026 The maintainers of the wxWidget related packages don't build a GTK2+ version of python-wxgtk3.0 package in Debian testing anymore. And this will not change for the Buster release. So we need to deal with this. This whole wx stuff and the relations between the various packages is getting more and more worse in my eyes. I don't what we or I can do to improve anything here. A possibility I see is to remove the package dependency on python-wxgtk3.0 and adding a Breaks instead because other binary packages can bring in a installation of this package at any time. As we have already disabled the Python scripting console (later) we don't really need python-wxgtk3.0 anymore in KiCad and I should have removed this dependency already earlier? Is there somewhere a explanation about the relationship of these wxwidget packages we can use to add some more answers to the readme?
Am 2018-11-18 11:18, schrieb Carsten Schoenert: That will be required for KiCad 5.1 as soon as the package works reliably with GTK3. As long as we are using the wxgtk3.0 built against GTK2, we need to maintain the python-wxgtk that is also built against GTK2. On Buster, this does not exist, so we will need to disable scripting for Buster until KiCad 5.1 is released. I agree. The decision to change python-wxgtk3.0 from GTK2 to GTK3 but keep the same package name was a poor one. At a minimum, I wish that they would have changed the name as the functionality is definitely not equivalent.
Hello Julien, Am 16.11.18 um 05:18 schrieb Julien Goodwin: I tried to reproduce this issue on several machines in preparation for 5.0.2. But I'm unable to get catched by your reported issue on any of my machines. Even if I forced the install the packages python-wxgtk3.0 and libwxgtk3.0-gtk3-0v5! No other user seems to be affected by the root of this report until now. I've not seen something similar in the KiCad user forum too. Also the backtrace shows to me that somehow functions called that should have been disabled (CMake option KICAD_SCRIPTING_WXPYTHON=OFF) for all versions since 5.0.0-1. Are you really sure you are using a binary from the Debian archive? Can you purge your current installation? If yes, did this happen too if you are work with fresh and clean config files for KiCad? Means all entries in ~/.config related to KiCad are created by the first time start of KiCad.
For me forcing python-wxgtk3.0_3.0.2.0+dfsg-4 is the way I make things work. ... Yes. I just upgraded to 5.0.2+dfsg1-1 last night, and before that played around. Having a python plugin (in .kicad/scripting/plugins, and specifically InteractiveHtmlBom[1]) seems to be what triggers this. So if python is intended to be disabled it's clearly not. 1: https://github.com/openscopeproject/InteractiveHtmlBom
Hello Julien, happy Xmas! Am 22.12.18 um 07:58 schrieb Julien Goodwin: Reading your answer completely it's quite obvious why. ... I've looked into the symbol table while KiCad is running and there are no GTK+3 related symbols loaded. So the clashing mus come from elsewhere. Starting KiCad, open EEschema with some ordinary schematic and open Cvpcb ... Searching the packages the libraries comes from. All these libraries are the GTK+2 variants. I see no problems on the KiCad packaging side. Yeah, looking at this add-on you see that it is including the modules 'wx' and 'wx.aui' which are provided by the package python-wxgtk3.0 and voilà, here we have the symbol clashing. This add-on is simply doing no checks at all if the environment is ready for get running this python scripting! And there is already a bug report in the issue tracker about the problem you do experience! https://github.com/openscopeproject/InteractiveHtmlBom/issues/47 But I hardly disagree with the rationale the author is writing, it's not the job of the KiCad devs to ensure that his add-on is working with KiCad, it's the responsibility of the author of this Python scripting to not just simply assume that KiCad is build with Python GTK+3 ready scripting support. All this add-on have to do is checking if KiCad is build with GTK+3 support and compare this with the GTK version of python-wxgtk3.0 comes. In the Debian packaging this can be found in /usr/lib/python2.7/dist-packages/wx-3.0-gtk3/wx/build/build_options.py It might be that python-kicad is currently missing some information about the build environment, so this should be than addressed to the KiCad devs to implement this. As there is nothing to be done within the packaging I've tagged this report with wontfix.
Hello Carsten, i have made my circuit diagram, but cvpcb is not working. The window opens, but when you click on a library, the component list is not actualized in the window right. So you can't assign the footprints to the components. KiCad is unusable, because at this point you can't proceed to layout. Best regards karsten
Hello, there is a workaround to install the backport package 5.1.8+dfsg1-1~bpo10+1. In this version the cvpcb is working. Best regards karsten
Hi, Am 28.11.20 um 11:17 schrieb Karsten: I can't reproduce this behavior. Seems to me you didn't use CvPcb the way it is intended. And btw., your message about your potential problem is completely wrong in this report.
Am 28.11.20 um 20:51 schrieb Carsten Schoenert: Hello Carsten, i am talking about the features behind the button "Assign PCB footprints to schematic symbols" (see screenshot). How this simple part of KiCad cannot be used as intended? Using the wrong hand for the mouse? :-) Fact is that this part of KiCad seems to be very buggy. I did not open a new bug report for it, because i thought the problems of the described problem are to similar. One time this part crashed, but this was really not reproducible. It's fine that it is running stable on your system. But this is no explanation that it must be stable everywhere. On the other hand i think that you can't do anything to solve this bugs. We must wait until this bugs are solved in newer versions of Kicad. Version 5.1.8 seems to be on the way ... Regards karsten
Hello Karsten, next time please start a new bug report. Now there is a cloned old report there the old history is completely indpendent from your issue. This makes it not easier to follow the red line. Am Sun, Nov 29, 2020 at 02:49:38AM +0100 schrieb Karsten: It's obvious to me what you are talking about. I know what CvPcb is doing. Simple things can be difficult if you don't know what the right is thing to do is clear to you. You say "It doesn't work", I've tested CvPcb from 5.0.2 with some of my projects and I don't see a problem, I can assign footprints what ever I like to assign. I can set the filtering from no filtering to the most strict filterung which is the only thing that has impact to the visible list with the footprints on the right. I have no idea what the point is where you assume CvPcb is broken. How can I readjust your situation? What your are doing (and what not). What other package you might have installed from backports or third party repositories which might have a bad interact with kicad from stable? But I don't think this is happen in any way. Any third party plugin installed which might have impact on your side? I disagree. I don't know any upstream bug report about CvPcb or from the KiCad forum from about the last two years. And I don't know some Git related history about bug fixing in this area within the 5.1 cycle. If you think your issue is related to the original report why don't you have written about this in first place? The other report has a lot of information how the library symbol clashing can be found and which library/symbol is the right combination. Have you really tried out these steps at your own? If your issue is really a upstream issue than it needs to be reported to the upstream developers. The KiCad team is really responsive and quick to fix such things once they have understand what problem is responsible for the visible behavior. You mean 5.1.9 for sure. I believe this report will start bit rotting, searching a possible issue in this rather old version is exhausting and mostly useless in my eyes as the current supported version is 5.1.8. Te current rules of the release team makes it hard to update the version of kicad in stable due rather big source code changes that are not related to the baisc rules for updates of packages in stable. I don't have really time to jump into work which nobody will use and honor somehow in the end. You have found a newer version in backport where you don't have problems with. And the backports archive is exactly the use case for newer versions with newer and improved features like KiCad upstream does within their release for the stable cycle. Regards Carsten
Hello Carsten, Am 29.11.20 um 07:17 schrieb Carsten Schoenert: O.K. Not for all of us under every circumstances. But you can see the reported bugs. You can define them as nonsense, but that will not fix the problem. This all makes no difference when you say it is running for you and there is no bug. There is no support of bugs in older versions as used in an stable distribution. This point of view is understandable, but does not help the user. I mean 5.1.8+dfsg1-1~bpo10+1 from the backports. We will see what will happen in later releases. Yes - thank you for your support so far! That's understandable. Besides Debian 10 is running less stable than Debian 8. There are many detail issues, but Debian 8 is not supported any more ... An upgrade to testing did fail too - maybe it is possible now. Yes - but first i didn't remember to look at the backports. It seems new that the pinning does not automatically update to a newer version when it exists. So it must be done manual for every main package. Best regards karsten
Yes, that is the idea of pinning. https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_tweaking_candidate_version
The main version this report ist about isn't under support by upstream since a long time. Also no new information was contributed to the report. I'll close this report now. Am Sun, Nov 29, 2020 at 02:49:38AM +0100 schrieb Karsten: