The database thing is a independent issue.
The other problem I have is crashes when I use 7.0.3 to open a file created in 7.0.2 (I have same problem with two 7.0.2 files) and either update-pcb-from-schematic or run-erc.
However, if I open a file created in 7.0.1, I do not have the crashes. Also fine if I open a 6.0.something file. Very odd.
I moved the file I was editing in 7.0.3 on linux (that crashed when I went to update pcb) to a win system that has 7.0.2 and it opened fine with schematic edits intact, and can update pcb just fine – so 7.0.3 schematic changes did not bother 7.0.2.
I turned off wifi on this win machine so I don’t get updated to 7.0.3 and will continue working on this isolated kicad laptop for now.
Which leads to a question: how to stop auto-update of kicad (both linux and win)? Then I can choose to update when I am not in the middle of a board design.
KiCad doesn’t auto-update itself on either platform, but on linux your package manager will probably install updates “automatically” (when you tell it to update).
Windows: you have to install the updates yourself by downloading an installer from the kicad.org website, nothing automatically happens. You can turn your wifi back on if you want.
Linux: presumably you installed KiCad through your distribution’s package manager. I don’t know how Pop OS works but on most linux distributions, your package manager will update your packages to the newest versions available whenever you tell it to run an update. The systems I’m familiar with don’t run this automatically - you run the update command and the package manager tells you what updates are available and you confirm. I would assume that’s what Pop OS does too but like I said I’m not familiar.
Thanks for the details @gkeeth. I need to look into the pop auto-update config. I will stay on the 7.0.2 win installation for now until I know if the crashes and database connection problems are related to 7.0.3 or perhaps specific to my installation.
I assume that you are running a flatpak install of KiCad (at least the build date in your version info matches the flathub stable build build time). In my local tests using this version, I can add symbols from a sqlite database library. Can you post the contents of the corresponding *.kicad_dbl file, esp. the contents of the "source" field?
If you go to the Pop OS software manager, can you check if the sqliteodbc Driver extension has been installed? This is required if you want to connect to an sqlite database using a flatpak install.
I can’t tell how it should look for your distribution, but on Fedora (Silverblue) 38, in GNOME Software there is a section called “Add-ons” where you can install the corresponding ODBC drivers. Make sure that sqliteodb is installed:
Alternatively, you can run flatpak install org.kicad.KiCad.ODBCDriver.sqliteodbc from the command line to install the installation system-wide (use --user if you only want to install it for your user installation).
Also, I am unable to reproduce any of the crashes you mention: Updating a PCB from the schematic, and ERC on a schematic works fine for me.
My kicad 7.0.3 linux system state is the same as yesterday – kicad cannot connect to the database. I can look at the db just fine with sqlitestudio or dbbrowser though. This database has been running properly on this system, and heavily used, for months now; the change that happened yesterday was the 7.0.3 update.
The pop-os package manager does not seem to have an add-ons or similar option to check. I tried the command line option and it says the driver is already installed:
gil@pop-os:~$ sudo flatpak install org.kicad.KiCad.ODBCDriver.sqliteodbc
[sudo] password for gil:
Looking for matches…
Skipping: org.kicad.KiCad.ODBCDriver.sqliteodbc/x86_64/stable is already installed
gil@pop-os:~$
This is one of my dbl files:
gil-db-main.kicad_dbl (21.2 KB)
Aaaaaaaaccchhhhh – my fault. I set kicad up on a win machine to figure out the database connection there, and I worked on that system for a few weeks to try it out (no dark mode, lots of icons look grayed out when they are not, but it worked well). I had made some db changes under win and brought those files back to the linux system – I forgot that the db connection was different between the systems.
Anyway, in the .kicad_dbl files under win, the connection looks like:
"source": {
"type": "odbc",
"dsn": "",
"username": "",
"password": "",
"timeout_seconds": 2,
"connection_string": "DSN=KiCad_gildb;"
},
and under linux it should be:
"source": {
"type": "odbc",
"dsn": "",
"username": "",
"password": "",
"timeout_seconds": 2,
"connection_string": ";Database=/home/gil/aaa-devo/kicad/gil-lib/database/gil-db.sqlite;Driver=SQLite3"
},
So that makes sense – I forgot all the hoops I jumped through getting the db running under windows and that the .kicad_dbl files had a different connection line.
Thanks for pushing me to look into the connection.
I do still have the crashes though – is there a dump or log somewhere?
Glad to hear that you were able to solve the db connection issue.
Regarding the crashes, you can collect crashlogs by following the guide from the flatpak documentation:
https://docs.flatpak.org/en/latest/debugging.html
In general it boils down to installing the freedesktop SDK and KiCad’s debug extension:
flatpak install org.kicad.KiCad.Debug
Then Open a shell to the sandbox with flatpak run --devel --command=sh org.kicad.KiCad, run gdb /app/bin/eeschema, reproduce the crash and collect the backtrace via thread apply all backtrace.
Well this is wading into uncharted territory for me, but I tried the following:
gil@pop-os:~$ flatpak install org.kicad.KiCad.Debug
Looking for matches…
Remotes found with refs similar to ‘org.kicad.KiCad.Debug’:
1) ‘flathub’ (system)
2) ‘flathub’ (user)
Which do you want to use (0 to abort)? [0-2]: 1
ID Branch Op Remote Download
1. [✓] org.kicad.KiCad.Debug stable i flathub 1.3 GB / 1.3 GB
Installation complete.
gil@pop-os:~$ flatpak run --devel --command=sh org.kicad.KiCad
[📦 org.kicad.KiCad ~]$ gdb /app/bin/eeschema
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /app/bin/eeschema...
Reading symbols from /usr/lib/debug//app/bin/eeschema.debug...
(gdb) thread apply all backtrace
(gdb)
I am unclear if that was done correctly or not. I ran kicad and created an erc crash just before typing the “thread apply all backtrace” part, but I really have no idea how gdb works, whether a dump was saved somewhere, or if I am doing this properly.
Can you share any of the projects that have this crash when running ERC? I tried some of mine and don’t see it.
I can’t post it publicly Jon.
I tried to message you to send it, but it is about 9 MB and the attachment limit is 4 MB. Is there another way I can send it to you?
The best way is to open a confidential issue on GitLab and attach it there. If you cannot do that, you can also email it to me MOD EDIT: (PM me for email address because bots scrape web pages for them)
Forgot to add, after starting gdb, the first command is run, to actually start the program you want to debug. thread apply all bt you enter after the crash has happened.
The dump will then, by default, be written to the terminal.
7.0.3 is not going to be officially released, 7.0.4 should be announced fairly soon
https://groups.google.com/a/kicad.org/g/devlist/c/Qr6G7MMSgVo
Thanks guys – I will try it with 7.0.4 when it arrives.
If you are able, it would be helpful if you could install the testing build and confirm if you don’t see any problems.
(this situation with 7.0.3 happened because nobody noticed this problem until after the actual release, and if more people use the testing build we can hopefully avoid future problems)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.