Not sure if this is related to the nightlies or my questionable housekeeping, but during a recent skirmish with wxwidgets, I installed some wx stuff with pip and some with pacman.
After getting it all sorted out, I was able to build the nightlies based of DX-MON’s excellent work in the AUR (namely, kicad-nightly).
Any ideas on what I should do to chase this down? I’m seeing crashes when I start the 3D viewer, and I can’t help but think that it may be related to this.
I get the same message when I start pcbnew using the stable kicad from the Arch community repo. No crashes in 3d viewer though, and no other issues as far as I can tell.
I am not an expert, but I think (could be wrong) the issue is that wxgtk3/wxgtk-common in the Arch repos were compiled with an older gcc (older ABI) than Kicad, and maybe wxpython as well. wxgtk3 and wxgtk-common were last rebuilt in May 2020, while wxpython and Kicad were last rebuilt in November, and gcc updated to a new ABI version in the meantime.
I think the solution would be for the Arch maintainers to rebuild wxgtk3 and/or wxgtk-common. However all other packages linked against wxgtk3 and wxgtk-common would need to be rebuilt as well, I think.
This error occurs when the ABI version of wxGTK that KiCAD was built against differs from the ABI version of wxGTK the operating system provides… the joys of C++…
This usually occurs when there is a compiler or wxGTK version bumped (as it comes with an ABI change as well…). All that is needed is KiCad needs to be rebuild against the new version of wxGTK the system provides with a consistent toolchain
Some examples of this happening on Gentoo where we chop and change libraries all the time. its more convoluted on Gentoo as we have the ability to slot packages
You shouldn’t install wxpython both from pip and from system repository. One of them might be causing your problem, I would start by removing the pip package and doing a clean build (important to clear cmake cache).
No, serving a new updated dynamically linked library is enough, so basically one file needs to get updated. It’s not like in the Go ecosystem where all is statically linked and all needs a rebuild in such a case. This has nothing to with any C++ internals.
I don’t know if this is a good crash report (i copied and pasted a gdb recipe from another topic on this site), but when I open the 3D viewer, this is what happens:
I would also mention that if I change the acceleration method or try to open the 3D settings on a component, I also get a crash…Again, not sure if this a good crash report or if this issue is related to the wxWidgets issue that I started this thread with, but I appreciate everyone’s help!
(kicad:40703): Gtk-CRITICAL **: 11:07:03.996: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkNotebook
(kicad:40703): Gtk-CRITICAL **: 11:07:04.003: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkScrollbar
(kicad:40703): Gdk-ERROR **: 11:07:04.129: The program 'kicad' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 158874 error_code 2 request_code 151 (GLX) minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Thread 1 "kicad" received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff65ce104 in g_log_writer_default () from /usr/lib/libglib-2.0.so.0
(gdb) b gdk_x_error
Function "gdk_x_error" not defined.
(gdb) bt
#0 0x00007ffff65ce104 in g_log_writer_default () at /usr/lib/libglib-2.0.so.0
#1 0x00007ffff65cb959 in g_log_structured_array () at /usr/lib/libglib-2.0.so.0
#2 0x00007ffff65cbeb1 in g_log_structured_standard () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff5f44577 in () at /usr/lib/libgdk-3.so.0
#4 0x00007ffff5c1daa5 in _XError () at /usr/lib/libX11.so.6
#5 0x00007fffe1e43ffc in () at /usr/lib/libGLX_mesa.so.0
#6 0x00007fffc2cadc20 in EDA_3D_CANVAS::initializeOpenGL() () at /usr/lib/kicad-nightly/bin/_pcbnew.kiface
#7 0x00007fffc2cb2a10 in EDA_3D_CANVAS::DoRePaint() () at /usr/lib/kicad-nightly/bin/_pcbnew.kiface
#8 0x00007ffff74af4c1 in wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () at /usr/lib/libwx_baseu-3.0.so.0
#9 0x00007ffff74af5c4 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) ()
at /usr/lib/libwx_baseu-3.0.so.0
#10 0x00007ffff74af90e in wxEvtHandler::TryHereOnly(wxEvent&) () at /usr/lib/libwx_baseu-3.0.so.0
#11 0x00007ffff74af994 in wxEvtHandler::ProcessEventLocally(wxEvent&) () at /usr/lib/libwx_baseu-3.0.so.0
#12 0x00007ffff74afa32 in wxEvtHandler::ProcessEvent(wxEvent&) () at /usr/lib/libwx_baseu-3.0.so.0
#13 0x00007ffff74b0441 in wxEvtHandler::ProcessPendingEvents() () at /usr/lib/libwx_baseu-3.0.so.0
#14 0x00007ffff7329cf0 in wxAppConsoleBase::ProcessPendingEvents() () at /usr/lib/libwx_baseu-3.0.so.0
#15 0x00007ffff78132fa in wxApp::DoIdle() () at /usr/lib/libwx_gtk3u_core-3.0.so.0
#16 0x00007ffff7813424 in () at /usr/lib/libwx_gtk3u_core-3.0.so.0
#17 0x00007ffff65c48f4 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#18 0x00007ffff6618821 in () at /usr/lib/libglib-2.0.so.0
#19 0x00007ffff65c3e43 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#20 0x00007ffff6a9b22f in gtk_main () at /usr/lib/libgtk-3.so.0
#21 0x00007ffff7830856 in wxGUIEventLoop::DoRun() () at /usr/lib/libwx_gtk3u_core-3.0.so.0
#22 0x00007ffff7365e0e in wxEventLoopBase::Run() () at /usr/lib/libwx_baseu-3.0.so.0#23 0x00007ffff732af27 in wxAppConsoleBase::MainLoop() () at /usr/lib/libwx_baseu-3.0.so.0
#24 0x00005555557358ca in ()
#25 0x00007ffff73b97f9 in wxEntry(int&, wchar_t**) () at /usr/lib/libwx_baseu-3.0.so.0
#26 0x000055555570eaa9 in ()
#27 0x00007ffff5fda152 in __libc_start_main () at /usr/lib/libc.so.6
#28 0x000055555572052e in _start ()
(gdb)
Won’t the ABI mismatch persist until until wx* and all packages that link against the wx* packages are rebuilt with the 1014 ABI version? Rebuilding the wx* packages will “update” them to the 1014 ABI, but any package that hasn’t been rebuilt will still expect the 1013 ABI. Unless I totally misunderstand how this works, which is possible
Arch is a rolling release distro, so rebuilding packages with older versions of gcc is going to be a non-starter. Any new or updated packages will be built with the newest version of gcc.
Edit: I see that gcc has a flag to specify a specific ABI, so you wouldn’t have to use an older gcc, but I still don’t think Arch packagers would pin at an older ABI version. It’s not super unusual for an update of some library, or python version, or whatever to trigger a mass-rebuild of a big swath of Arch packages.
I’m not familiar with arch packaging system but the listing in first post suggests that wxpython is installed from “community” repository. If it’s anything like ubuntu ppa or another 3rd party repo then choosing a different repo with package that actually works with your system would be a start.
I understand the confusion, it’s a bit misleadingly named in this case, but the kicad package in Arch’s community repository is the official 5.1.8 package. Community is not equivalent to an Ubuntu PPA or 3rd party repo.
Too much background info, if you’re curious:
The community repo is one of Arch’s 3 official repositories (Core, Community, and Extra) of prebuilt packages that are “centrally managed” so to speak. The “community” name just means that an application gets added to this repo after being voted on by the community and adopted by a Trusted User. After being added to the repo, it has the same status as any other official package, with the caveat that if the Trusted User no longer wants to maintain it, it’s more likely to be removed from the repo unless someone steps up to maintain it. Packages in Core and Extra are considered more essential and the distribution would ensure that someone is assigned to maintain them.
I think the Arch User Repository is closer to what you’re picturing – anyone can submit a recipe to package some software, and if it needs to be built from source that happens on the user’s local machine.
There are many versions of kicad in the AUR (various 5.1-git, 5.99-git, and nightly versions), but the official Arch kicad package is the one in community, where there is currently an ABI mismatch.
Ok, thanks for the info. But in this case problem is not with kicad, the problem is with wxpython package which is built with different ABI then the wxpackage that it depends on. Anything using wxpython on such system will have issues, not just kicad.
If that package is from “centrally managed” repo then it’s not managed very well. I’d suggest reaching out to maintainer of that package for ideas on how to resolve the issue, it’s unlikely that they built and submitted to the repository a package that never works. It’s more likely that we are missing something.
Yep, the problem is with the wx* packages and not with Kicad, and the solution is to rebuild the wx package(s) (if I understand the problem correctly, which is not always a good assumption). That’s what I said in my first reply
However, I think that wxPython in particular is not the issue, as it was rebuilt last week (package update date 2020-12-02), and the error says wxPython is at ABI 1014 (the latest). It’s wxgtk3 and maybe wxgtk-common that need to be rebuilt.
I’m planning to report the issue to the packager(s) if no one beats me to it, but it’s not the top of my priority list at the moment. At least in my case, the only issue I’ve run into is I need to click “okay” to the warning about the ABI mismatch. I haven’t seen any crashes or other issues.
