Bug#913864: kicad: Backtraces on opening cvpcb
Control: tags -1 wontfix Hello Julien, happy Xmas! Am 22.12.18 um 07:58 schrieb Julien Goodwin: > On 15/12/18 5:34 pm, Carsten Schoenert wrote: >> 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! > > For me forcing python-wxgtk3.0_3.0.2.0+dfsg-4 is the way I make things work. Reading your answer completely it's quite obvious why. ... >> Are you really sure you are using a binary from the Debian archive? Can > 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. 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 ... > $ grep libwx /proc/$(pidof kicad)/maps > 7fea4d7d7000-7fea4d802000 r--p 103:01 1057723 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0 > 7fea4d802000-7fea4d9e1000 r-xp 0002b000 103:01 1057723 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0 > 7fea4d9e1000-7fea4da17000 r--p 0020a000 103:01 1057723 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0 > 7fea4da17000-7fea4da1e000 r--p 0023f000 103:01 1057723 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0 > 7fea4da1e000-7fea4da1f000 rw-p 00246000 103:01 1057723 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_stc-3.0.so.0.4.0 > 7fea4da22000-7fea4da26000 r--p 103:01 1056297 > /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0 > 7fea4da26000-7fea4da2e000 r-xp 4000 103:01 1056297 > /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0 > 7fea4da2e000-7fea4da31000 r--p c000 103:01 1056297 > /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0 > 7fea4da31000-7fea4da32000 ---p f000 103:01 1056297 > /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0 > 7fea4da32000-7fea4da33000 r--p f000 103:01 1056297 > /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0 > 7fea4da33000-7fea4da34000 rw-p 0001 103:01 1056297 > /usr/lib/x86_64-linux-gnu/libwx_baseu_xml-3.0.so.0.4.0 > 7fea4da34000-7fea4da96000 r--p 103:01 1052315 > /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0 > 7fea4da96000-7fea4dc38000 r-xp 00062000 103:01 1052315 > /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0 > 7fea4dc38000-7fea4dcc3000 r--p 00204000 103:01 1052315 > /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0 > 7fea4dcc3000-7fea4dcc4000 ---p 0028f000 103:01 1052315 > /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0 > 7fea4dcc4000-7fea4dccf000 r--p 0028f000 103:01 1052315 > /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0 > 7fea4dccf000-7fea4dcd3000 rw-p 0029a000 103:01 1052315 > /usr/lib/x86_64-linux-gnu/libwx_baseu-3.0.so.0.4.0 > 7fea4dce-7fea4dcf1000 r--p 103:01 1054165 > /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0 > 7fea4dcf1000-7fea4dd18000 r-xp 00011000 103:01 1054165 > /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0 > 7fea4dd18000-7fea4dd25000 r--p 00038000 103:01 1054165 > /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0 > 7fea4dd25000-7fea4dd26000 ---p 00045000 103:01 1054165 > /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0 > 7fea4dd26000-7fea4dd28000 r--p 00045000 103:01 1054165 > /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0 > 7fea4dd28000-7fea4dd29000 rw-p 00047000 103:01 1054165 > /usr/lib/x86_64-linux-gnu/libwx_baseu_net-3.0.so.0.4.0 > 7fea4dd2a000-7fea4df3d000 r--p 103:01 1057066 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0 > 7fea4df3d000-7fea4e20e000 r-xp 00213000 103:01 1057066 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0 > 7fea4e20e000-7fea4e30f000 r--p 004e4000 103:01 1057066 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0 > 7fea4e30f000-7fea4e381000 r--p 005e4000 103:01 1057066 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0 > 7fea4e381000-7fea4e389000 rw-p 00656000 103:01 1057066 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-3.0.so.0.4.0 > 7fea4e395000-7fea4e3d5000 r--p 103:01 1057407 > /usr/lib/x86_64-linux-gnu/libwx_gtk2u_html-3.0.so.0.4.0 > 7fea4e3d5000-7fea4e43e000 r-xp 0004 103:01 1057407
Bug#913864: kicad: Backtraces on opening cvpcb
On 15/12/18 5:34 pm, Carsten Schoenert wrote: > 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! For me forcing python-wxgtk3.0_3.0.2.0+dfsg-4 is the way I make things work. ... > 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 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
Bug#913864: kicad: Backtraces on opening cvpcb
Control: tags -1 moreinfo unreproducible Hello Julien, Am 16.11.18 um 05:18 schrieb Julien Goodwin: > On opening cvpcb there's many (408) backtraces, bypassing them does allow > cvpcb to work, but closing it crashes kicad. 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! > 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. 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. -- Regards Carsten Schoenert
Bug#913864: kicad: Backtraces on opening cvpcb
Am 2018-11-18 11:18, schrieb Carsten Schoenert: Hello Seth, Am 17.11.18 um 05:34 schrieb Seth Hillbrand: Hi Julien- Am 2018-11-16 22:37, schrieb Julien Goodwin: 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. 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. 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. 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. 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 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. -Seth
Bug#913864: kicad: Backtraces on opening cvpcb
Hello Seth,
Am 17.11.18 um 05:34 schrieb Seth Hillbrand:
> Hi Julien-
> Am 2018-11-16 22:37, schrieb Julien Goodwin:
>> 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.
>
> 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.
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.
> $ git show 35b932c4a
> commit 35b932c4ad0ef184d18f1d72ca81fef6c21dc026
> Author: Carsten Schoenert
> Date: Sun Apr 8 14:29:17 2018 +0200
>
> kicad: adding versioned Depends for python-wxgtk3.0
>
> Related to the GTK3 bindings we need python-wxgtk3.0 at least with
> version 3.0.2.0+dfsg-7.
>
> diff --git a/debian/control b/debian/control
> index af4a9d8a..6f050e19 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -78,7 +78,7 @@ Homepage: http://www.kicad-pcb.org
> Package: kicad
> Architecture: any-amd64 any-i386 arm64 armhf
> Depends:
> - python-wxgtk3.0,
> + python-wxgtk3.0 (>= 3.0.2.0+dfsg-7~),
> ${misc:Depends},
> ${python:Depends},
> ${shlibs:Depends},
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?
--
Regards
Carsten Schoenert
Bug#913864: kicad: Backtraces on opening cvpcb
Hi Julien- Am 2018-11-16 22:37, schrieb Julien Goodwin: 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. 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
Bug#913864: kicad: Backtraces on opening cvpcb
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. On 17/11/18 5:34 am, Seth Hillbrand wrote: > Am 2018-11-16 12:39, schrieb Carsten Schoenert: >> So downgrading is a bit difficult and right now before the soft freeze >> for Buster not the right way I think. > > 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. > > -Seth
Bug#913864: kicad: Backtraces on opening cvpcb
Am 2018-11-16 12:39, schrieb Carsten Schoenert: So downgrading is a bit difficult and right now before the soft freeze for Buster not the right way I think. 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. -Seth
Bug#913864: kicad: Backtraces on opening cvpcb
Am 16.11.18 um 15:28 schrieb Seth Hillbrand: > Hello Carsten- > Am 2018-11-16 02:00, schrieb Carsten Schoenert: >> 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? > > 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. 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. > $ rmadison libwxgtk3.0-0v5 libwxbase3.0-0v5 python-wxgtk3.0 > libwxbase3.0-0v5 | 3.0.2+dfsg-4| stable | amd64, arm64, > armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > libwxbase3.0-0v5 | 3.0.4+dfsg-4~bpo9+1 | stretch-backports | amd64, arm64, > armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > libwxbase3.0-0v5 | 3.0.4+dfsg-4| testing| amd64, arm64, > armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > libwxbase3.0-0v5 | 3.0.4+dfsg-4| unstable | amd64, arm64, > armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, > mipsel, ppc64el, s390x > libwxgtk3.0-0v5 | 3.0.2+dfsg-4| stable | amd64, arm64, > armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > libwxgtk3.0-0v5 | 3.0.4+dfsg-4~bpo9+1 | stretch-backports | amd64, arm64, > armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > libwxgtk3.0-0v5 | 3.0.4+dfsg-4| testing| amd64, arm64, > armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > libwxgtk3.0-0v5 | 3.0.4+dfsg-4| unstable | amd64, arm64, > armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, > mipsel, ppc64el, s390x > python-wxgtk3.0 | 3.0.1.1+dfsg-2 | oldstable | amd64, arm64, > armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x > python-wxgtk3.0 | 3.0.1.1+dfsg-2 | oldstable-kfreebsd | kfreebsd-amd64, > kfreebsd-i386 > python-wxgtk3.0 | 3.0.2.0+dfsg-4 | stable | amd64, arm64, > armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > python-wxgtk3.0 | 3.0.2.0+dfsg-8 | testing| amd64, arm64, > armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x > python-wxgtk3.0 | 3.0.2.0+dfsg-8 | unstable | amd64, arm64, > armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, > mipsel, ppc64el, s390x 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. -- Regards Carsten Schoenert
Bug#913864: kicad: Backtraces on opening cvpcb
Hello Carsten- Am 2018-11-16 02:00, schrieb Carsten Schoenert: 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? 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. -Seth You will need a DGB log? Am 16.11.18 um 05:18 schrieb Julien Goodwin: ii libwxbase3.0-0v53.0.4+dfsg-4 ii libwxgtk3.0-0v5 3.0.4+dfsg-4 ii python-wxgtk3.0 3.0.2.0+dfsg-8
Bug#913864: kicad: Backtraces on opening cvpcb
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: > Package: kicad > Version: 5.0.1+dfsg1-3 > Severity: important > > 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 > > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE= > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages kicad depends on: > ii libc6 2.27-8 > ii libcairo2 1.16.0-1 > ii libcurl47.61.0-1 > ii libfreeimage3 3.17.0+ds1-5+b5 > ii libfreetype62.8.1-2 > ii libgcc1 1:8.2.0-9 > ii libgl1 1.1.0-1 > ii libglew2.0 2.0.0-6 > ii libglu1-mesa [libglu1] 9.0.0-2.1 > ii libice6 2:1.0.9-2 > ii libngspice0 29-1 > ii liboce-foundation11 0.18.2-3 > ii liboce-modeling11 0.18.2-3 > ii liboce-ocaf-lite11 0.18.2-3 > ii liboce-ocaf11 0.18.2-3 > ii liboce-visualization11 0.18.2-3 > ii libpixman-1-0 0.34.0-2 > ii libpython2.72.7.15-4 > ii libsm6 2:1.2.2-1+b3 > ii libssl1.1 1.1.1-2 > ii libstdc++6 8.2.0-9 > ii libwxbase3.0-0v53.0.4+dfsg-4 > ii libwxgtk3.0-0v5 3.0.4+dfsg-4 > ii libx11-62:1.6.7-1 > ii libxext62:1.3.3-1+b2 > ii python 2.7.15-3 > ii python-wxgtk3.0 3.0.2.0+dfsg-8 > > Versions of packages kicad recommends: > ii kicad-demos 5.0.1+dfsg1-3 > ii kicad-libraries 5.0.1+dfsg1-3 > ii xsltproc 1.1.32-2 > > Versions of packages kicad suggests: > ii extra-xdg-menus 1.0-4 > ii kicad-doc-en 5.0.1+dfsg1-3 > ii kicad-packages3d 5.0.1-1 > > -- no debconf information > -- Regards Carsten Schoenert
Bug#913864: kicad: Backtraces on opening cvpcb
Package: kicad Version: 5.0.1+dfsg1-3 Severity: important 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 -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kicad depends on: ii libc6 2.27-8 ii libcairo2 1.16.0-1 ii libcurl47.61.0-1 ii libfreeimage3 3.17.0+ds1-5+b5 ii libfreetype62.8.1-2 ii libgcc1 1:8.2.0-9 ii libgl1 1.1.0-1 ii libglew2.0 2.0.0-6 ii libglu1-mesa [libglu1] 9.0.0-2.1 ii libice6 2:1.0.9-2 ii libngspice0 29-1 ii liboce-foundation11 0.18.2-3 ii liboce-modeling11 0.18.2-3 ii liboce-ocaf-lite11 0.18.2-3 ii liboce-ocaf11 0.18.2-3 ii liboce-visualization11 0.18.2-3 ii libpixman-1-0 0.34.0-2 ii libpython2.72.7.15-4 ii libsm6 2:1.2.2-1+b3 ii libssl1.1 1.1.1-2 ii libstdc++6 8.2.0-9 ii libwxbase3.0-0v53.0.4+dfsg-4 ii libwxgtk3.0-0v5 3.0.4+dfsg-4 ii libx11-62:1.6.7-1 ii libxext62:1.3.3-1+b2 ii python 2.7.15-3 ii python-wxgtk3.0 3.0.2.0+dfsg-8 Versions of packages kicad recommends: ii kicad-demos 5.0.1+dfsg1-3 ii kicad-libraries 5.0.1+dfsg1-3 ii xsltproc 1.1.32-2 Versions of packages kicad suggests: ii extra-xdg-menus 1.0-4 ii kicad-doc-en 5.0.1+dfsg1-3 ii kicad-packages3d 5.0.1-1 -- no debconf information
