Broken footprint causes silent failure

Can you provide an example library?

Hmm... actually, it's a bit more subtle than this. I tried just removing one close-paren and I did get a proper error message. So I tried to replicate the *exact* problem I had, which is that an entire set of them was missing (every close-paren from every fp_line object). That did it. Now, I'm having a hell of a time trying to narrow it down to any single missing paren, as most of them seem to trigger the problem if removed! Unfortunately, I have *no* idea what's going on here.

But here's a library for you, full of auto-generated 100mil headers. I removed the final parenthesis from line 8 (the first fp_line) of CONN-100MIL-F-1x15.kicad_mod, and KiCad will silently fail to load any footprints past there.

If I load the single file manually, I get the correct error again (PARSE_ERROR: Expecting 'layer or width' in input/source 'clipboard'). However, opening the entire library gives silent failure.

When I load that, I do get that error once, but then it loads many if not all. How many do you expect me to see? (There were more than I dared to count.)

Sorry about that. Assuming it loads in 'ASCIIbetical' order, which it seems to, everything past CONN-100MIL-F-1x15 should be missing, most obviously including CONN-100MIL-F-1x16.

Interesting that you do get the error once. I also seem to get it occasionally, and can't really figure out what sets apart the times when I do not.

Actually, it seems not to be in a particular order. I *do* see 1x17! But F-1x16 is missing, as shown in the attachment, as well as F-1x14, and a few seemingly random others.

I confirmed the behavior but I'm not sure what the correct solution should be. There are two potential solutions that would not require a significant design change of the footprint library caching code. I could remove all of the footprints already in the cache if any of the footprint files is corrupt in a library. This would prevent the odd behavior you see when you click on the library again and only see the footprints cached up to the first corrupt file. The other option which would truly be silent is to ignore all corrupt footprint files and only show the ones that where correctly parsed. I prefer the former since it flags the user that the library is corrupt and it needs to fixe. It only takes on bad file for the library to be corrupt. Silently ignoring corrupt footprint library files is IMO is a bug as well. My guess is the corrupt file was generated by a script or edited by hand. In which case same on the person that did that. If footprint file was generated by KiCad, shame on me.

"My guess is the corrupt file was generated by a script or edited by hand. In which case same on the person that did that. If footprint file was generated by KiCad, shame on me."

Yup, generated by a script, I said that. It's still quite a big bug - it results in an entire library being able to be rendered unusable if a single byte is corrupted somewhere in just one file. It should at least be able to reject the file.

On 2/19/2015 9:58 PM, Chris Pavlina wrote:
> "My guess is the corrupt file was generated by a script or edited by
> hand. In which case same on the person that did that. If footprint file
> was generated by KiCad, shame on me."
>
> Yup, generated by a script, I said that. It's still quite a big bug - it
> results in an entire library being able to be rendered unusable if a
> single byte is corrupted somewhere in just one file. It should at least
> be able to reject the file.
>
It's exactly as big a bug as the legacy footprint file design where any
corruption in a library file would ignore the whole file which could
contain many footprints even if most of the file was successfully
parsed. The only difference is now a library is a folder with one
footprint per file. I will fix the confusing behavior of showing the
partial cache the next time the library is selected but I'm not sure I
like parsing only the files that are not corrupted and ignoring the
corrupted ones. I see a bug file being reported against this behavior
because someone will inevitably want to use the footprint that wasn't
parsed.

I am seeing similar behaviour still, when loading a library that contains footprints that KiCad interprets as "corrupted". Any footprints that are AFTER the bad footprint will not load (silently).

However, "corrupted" in some cases can mean "made using a future version of KiCad" e.g. using roundrect pads, as we recently experienced with someone uploading a nightly footprint to the Github libraries.

I was hoping to find a simple place to "fix" this in the code but it's nested deep within a burrow of try/catch statements that surround the loading of the *entire* lib not individual footprints.

As far as I can tell this is caused at Line 300 of kicad_plugin.cpp

I think the best solution is to mark each failed footprint as such, continue to load the remainder, than *then* inform the user of each footprint that failed, and why.

I committed a fix for this in 096d9fbbf. Please test it when you get a
chance an let me know if you find any issues.

On 3/14/2017 8:05 AM, Oliver wrote:
> I am seeing similar behaviour still, when loading a library that
> contains footprints that KiCad interprets as "corrupted". Any footprints
> that are AFTER the bad footprint will not load (silently).
>
> However, "corrupted" in some cases can mean "made using a future version
> of KiCad" e.g. using roundrect pads, as we recently experienced with
> someone uploading a nightly footprint to the Github libraries.
>
> I was hoping to find a simple place to "fix" this in the code but it's
> nested deep within a burrow of try/catch statements that surround the
> loading of the *entire* lib not individual footprints.
>
> As far as I can tell this is caused at Line 300 of kicad_plugin.cpp
>
> I think the best solution is to mark each failed footprint as such,
> continue to load the remainder, than *then* inform the user of each
> footprint that failed, and why.
>

Fixed in revision 096d9fbbf9946d671f48e21b71d75c4b726584b6
https://git.launchpad.net/kicad/patch/?id=096d9fbbf9946d671f48e21b71d75c4b726584b6

Wayne, it looks like it has fixed it :) Thanks!