Assert in eeschema during Remap

[Kevin Cozens]

I'm trying to open a schematic created with a version of Kicad that I built from git master before all the recent major changes to the library system. The eeschema program was configured to use the libraries on github, then local libraries, then my own custom libraries. I'm getting an assert when eeschema enters the Remap process.

I get the following assert:
/home/kcozens/Projects/Kicad/kicad/eeschema/dialogs/dialog_symbol_remap.cpp(306): assert "aPathA.IsAbsolute()" failed in normalizeAbsolutePaths(): Arguement 'aPathA' must be an absolute path.

Minor point: the word "Arguement" appears to be in French or the extra e is a typo.

I modified the code to show the file path it didn't like:
wxCHECK_MSG( aPathA.IsAbsolute(), false, aPathA.GetPath() );

/home/kcozens/Projects/Kicad/kicad/eeschema/dialogs/dialog_symbol_remap.cpp(306): assert "aPathA.IsAbsolute()" failed in normalizeAbsolutePaths(): https:/github.com/KiCad

The other thing to note here is https:// has been converted to https:/

[Wayne Stambaugh (stambaughw)]

On 11/11/2017 11:58 AM, Kevin Cozens wrote:
> Public bug reported:
>
> I'm trying to open a schematic created with a version of Kicad that I
> built from git master before all the recent major changes to the library
> system. The eeschema program was configured to use the libraries on
> github, then local libraries, then my own custom libraries. I'm getting
> an assert when eeschema enters the Remap process.
>
> I get the following assert:
> /home/kcozens/Projects/Kicad/kicad/eeschema/dialogs/dialog_symbol_remap.cpp(306): assert "aPathA.IsAbsolute()" failed in normalizeAbsolutePaths(): Arguement 'aPathA' must be an absolute path.

Like the footprint library table, the symbol library table requires
absolute paths. If the remapping code cannot normalize a relative path,
it will fail. This typically happens when you have defined a relative
path and then moved you project to a different folder where the relative
path can not be normalized. Absolute paths are always a train wreck
waiting to happen.

>
> Minor point: the word "Arguement" appears to be in French or the extra e
> is a typo.

It's a typo. I'll fix it when I find the time.

>
>
> I modified the code to show the file path it didn't like:
> wxCHECK_MSG( aPathA.IsAbsolute(), false, aPathA.GetPath() );
>
> /home/kcozens/Projects/Kicad/kicad/eeschema/dialogs/dialog_symbol_remap.cpp(306):
> assert "aPathA.IsAbsolute()" failed in normalizeAbsolutePaths():
> https:/github.com/KiCad

Huh? There never has and likely never will be a github plugin for
symbol libraries nor did the previous symbol library list support
loading files from https urls. I have no idea how you would have ended
up with https://github.com/KiCad in your symbol library table unless you
did it yourself. If you did, please remove it because it is wrong.

>
> The other thing to note here is https:// has been converted to https:/

That's probably because normalizeAbsolutePath probably treated it like a
normal file which it is not.

>
> ** Affects: kicad
> Importance: Undecided
> Status: New
>

[Wayne Stambaugh (stambaughw)]

I pushed a commit that improved the assert message and will tag this bug report as fix committed. Technically there is no bug as neither the symbol library table nor the old symbol library list have ever supported urls. If you see the assert with a legitimate file path, please change the status of this bug report and include a copy of your global symbol library table and the project file that you are trying to remap before it was remapped.

[Armin van der Togt (arminvdt)]

I have exactly the same error with the same path. As far as I can tell, the path is not in the project files or in my configuration files (I removed the entire .config/kicad dir and still got the same error). So... I think the problems is more than just configuration.

[Wayne Stambaugh (stambaughw)]

Please attach the sym-lib-table file from your user configuration and
the project file (.pro) prior to remapping that is causing the issue.

On 11/13/2017 3:25 PM, Armin van der Togt wrote:
> I have exactly the same error with the same path. As far as I can tell,
> the path is not in the project files or in my configuration files (I
> removed the entire .config/kicad dir and still got the same error).
> So... I think the problems is more than just configuration.
>

[KiCad Janitor (kicad-janitor)]

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

[Kevin Cozens (qq3dh7wn6set-fehmn-mm0v6n6x10rb)]

I was having a lot of problems with loading up schematic files created before the recent major changes in the library system. Amongts other problem I was also getting the asserts about https://github.com/ not being an absolute path. I couldn't find any reference to the path other than as the path associated with a default env var as shown in Preferences -> Configure Paths.

Looking at my env vars and the associated paths I noticed that the paths for KICAD_PTEMPLATES and KICAD_SYMBOL_DIR both ended in / where all env vars did not. I removed the trailing / from the paths used for those two env vars and all the problems I was having have gone away.

I was able to load up one of my old schematics, go through the symbol rescue and remap process, see a schematic looking the way it used to look, then save it and reload it without any further problem.

Additional note: I removed my ~/.config/kicad directory to check the paths set by default. All paths looked good (ie. no trailing /) except for KISYS3DMOD which did end in a /. I suspect that may cause problems in other parts of KiCad.

[Kevin Cozens (qq3dh7wn6set-fehmn-mm0v6n6x10rb)]

If a trailing / is going to cause a problem when paths to global and project libraries already have a / after the env var reference the path editor should automatically remove any trailing / in provided paths.

[Wayne Stambaugh (stambaughw)]

There is a problem with this. If a user includes the trailing separator
and does something like ${SOME_ENV_VAR}lib_file.lib. This will break.
In other words, the user is responsible for ensuring environment
variables and/or library table entries are valid. I don't know how else
to do this. Making the assumption that ${SOME_ENV_VAR}lib_file.lib is
an environment variable may not be accurate. On some platforms
${SOME_ENV_VAR}lib_file.lib may be a legitimate file name.

On 11/14/2017 12:52 PM, Kevin Cozens wrote:
> If a trailing / is going to cause a problem when paths to global and
> project libraries already have a / after the env var reference the path
> editor should automatically remove any trailing / in provided paths.
>

[Kevin Cozens (qq3dh7wn6set-fehmn-mm0v6n6x10rb)]

The best option may be to go with requiring a user to add a / between the env var reference and the name of the library file. That would be consistent with the paths to the library files generated by kicad-library. If the user left in a / at the end of a path in the env vars you would wind up with a double / when the path to the library is expanded (ie. the path associated with the env var is substituted for the env var reference). That leads to possible // in path names to library files and that leads to problems. When the path to a library file is expanded any // should be converted to just a / before use to avoid problems.

It may be simpler to just have the program trim trailing / off the end of paths when setting one for an env var and providing a guideline in a doc (or FAQ) that you put a / after the env var and before the file name.

I suspect other people will get bitten by this issue if it is not sorted out before 5.0 is released.

[KiCad Janitor (kicad-janitor)]

Fixed in revision 41a9007b6d3afe62c41b142adf3de1a5689fbe21
https://git.launchpad.net/kicad/patch/?id=41a9007b6d3afe62c41b142adf3de1a5689fbe21

[Wayne Stambaugh (stambaughw)]

I just push a fix for the assertion. Please let me know if this does not resolve this issue.

[Jon Neal (reportingsjr)]

I'm running commit 41f9c19 which has your most recent commit in it. I still got bitten by this issue where it complained about not being able to find default libraries due to the trailing slash.

Luckily I'm using git so I was able to remove the trailing slash from the environment variable and remap the libraries. No more trashed schematic, yay!

At the same time that I had this issue another person in IRC had the same problem. I expect this problem will be very widespread.

I don't think this is related to the original assertion. Should I open a new bug report?

[Wayne Stambaugh (stambaughw)]

On 11/15/2017 10:46 PM, Jon Neal wrote:
> I'm running commit 41f9c19 which has your most recent commit in it. I
> still got bitten by this issue where it complained about not being able
> to find default libraries due to the trailing slash.

I'm assuming that by trailing separator, you mean that there is a
training separator in the environment variable.

>
> Luckily I'm using git so I was able to remove the trailing slash from
> the environment variable and remap the libraries. No more trashed
> schematic, yay!
>
> At the same time that I had this issue another person in IRC had the
> same problem. I expect this problem will be very widespread.
>
> I don't think this is related to the original assertion. Should I open a
> new bug report?
>

Since this is a different issue, please file new bug report.

[Kevin Cozens (qq3dh7wn6set-fehmn-mm0v6n6x10rb)]

If Jon doesn't file one I will. I still see problems when there is a trailing / on the path for KICAD_SYMBOL_DIR.