[8.0.0~rc2] Unable to reopen saved PCB, (data corruption?)

yesterday i started working with 8.0.0-rc2, all seems fine and i’ve almost finished a simple PCB,
for a planar transformer (here attached), closed KC, commited the work, and closed the shop for the day.
Today a sad beginning: i cannot open the PCB anymore:

WPT.kicad_pcb (185.5 KB)

image

opening with a text editor doesn’t show anything overly strange on the file.
Further analisys: any pcb i start with 8.0 seems to work until i save it and reopen.

Can someone try to open the attached file or spot something broken inside?

Application: KiCad x86_64 on x86_64

Version: 8.0.0~rc2-1e5b68cb87~176~ubuntu22.04.1, release build

Libraries:
	wxWidgets 3.2.1
	FreeType 2.11.1
	HarfBuzz 2.7.4
	FontConfig 2.13.1
	libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.16

Platform: Ubuntu 22.04.3 LTS, 64 bit, Little endian, wxGTK, X11, mate, x11

Build Info:
	Date: Jan 31 2024 15:06:42
	wxWidgets: 3.2.1 (wchar_t,wx containers) GTK+ 3.24
	Boost: 1.74.0
	OCC: 7.5.2
	Curl: 7.81.0
	ngspice: 40
	Compiler: GCC 11.4.0 with C++ ABI 1016

Build settings:

I also get the same error for line 1130, but when looking at your file, there is nothing that indicates an error on that line.

...
1120			(uuid "961b1c5a-7cb7-4ada-b24e-983cf47765d0")
1121			(effects
1122				(font
1123					(size 1 1)
1124					(thickness 0.15)
1125				)
1126				(justify mirror)
1127			)
1128		)
1129		(property "ki_description" "PCB connector, Pin strip, 1 contact, 1 row, male, Straight, b to b, nolock, nokey, THD"
1130			(at 0 0 180)
1131			(unlocked yes)
1132			(layer "B.Fab")
1133			(hide yes)
1134			(uuid "8c79d41c-6b6d-411e-8b59-55960e5c7cf4")
1135			(effects
1136				(font
1137					(size 1 1)
1138					(thickness 0.15)
1139				)
1140				(justify mirror)
1141			)
1142		)
...

There are also 4 identical instances of line 1129 (With the same “ki_description”) and that is the first instance of those 4. I can not help with this. I guess it’s time for a bug report on gitlab

1 Like

I am running the Feb. 12 version.

Maybe worth updating?

Updates don’t work for me at the moment. See:

For some reason, it does not like property name “ki_description”. Changed all occurences of “ki_description” to “kidescr” and file opened properly.

2 Likes

Same for me. I changed all 4 instances of “ki_description” to “kiescription” and KiCad was open it normally after that.

Seems like “ki_description” is some internally used name that confuses the parser.
With a different project, I’ve added the “ki_description” field to a footprint, saved the file and it became corrupt. So this seems to be a kicad bug, that it allows to use it as a name using GUI.

I can confirm this also and it’s clearly a bug.
Either the creation of a “ki_description” field shout be disallowed in the first place or the file loading should be corrected.

1 Like

Thanks a lot to everybody,
the modification worked for me too! you saved my day :slight_smile:

@mf_ibfeew do you need a report on GL?

1 Like

do you need a report on GL?

Yes, please open a issue. I can’t open it myself the next hours (no access from this place).

1 Like
5 Likes

I think that the problem has been sorted out.
To add an explanation of what happened, it all originates from an error on my side on the of the .kicad_dbl file:

....
                {
                    "column": "Code_Description",
                    "name": "ki_description",
                    "visible_on_add": false,
                    "visible_in_chooser": true
                }
...

this add a field ‘ki_description’ (that is a reserved keyword) when placing the part.
It should have been:

...
             {
                    "column": "Code_Description",
                    "name": "Description",
                    "visible_on_add": false,
                    "visible_in_chooser": true
                }
...

HTH
C.

The thing is, you can add the “ki_description” field using GUI operations (Edit footprint > “+” to Add custom field > type “ki_description” as the field name > fill some value) and save file. This causes the file to be unopenable in the way you’ve discovered.
This should be prevented by code.

Yes, but i also suspect that is possible that placement from DB can bypass some of the countermeasures you place in the UI. i added a note to the GH issue to clarify the way i suspect it all happened.