Kicad nightly schematic crashes opening project

[Michael Heidinger]

In Kicad nightly the schematic editor crashes opening the following project.
https://gitlab.com/greenscreenflicker/rs232iso_v3
Commit of above rep. ad3d8969d9823b969c1c83910dc9baf367174d9e
The console returns a segfault and kicad cloeses.

[Michael Heidinger (mch-heidinger)]

It seems to be a generic issue on ubuntu, every project to open fails.

Version information:
Application: kicad
Version: 6.0.0-rc1-unknown-829ba27~83~ubuntu17.10.1, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0 (+libidn2/2.0.2) librtmp/2.3
Platform: Linux 4.13.0-46-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.55.1
    Compiler: GCC 7.2.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON

[Jeff Young (jeyjey)]

NOT Ubuntu-specific:

/Users/jeff/kicad_dev/kicad/eeschema/sch_legacy_plugin.cpp(2335): assert "m_libFileName.IsAbsolute()" failed in Load(): Cannot use relative file paths in legacy plugin to open library "C:/Program Files/KiCad/share/kicad/library/Interface_USB.lib".

Did you perchance Cancel when it asked if you wanted to remap your project?

[Jeff Young (jeyjey)]

@Wayne, I'm not familiar with re-mapping, etc. so I thought I'd ping you on this. (I don't even know if mapping is related to Michael's issue, but it sort of rang some bells....)

[Jeff Young (jeyjey)]

In any case, we probably need to change this assert to an error dialog and a graceful decline to open the file?

[Wayne Stambaugh (stambaughw)]

@Jeff, this is an internal requirement so the assertion is doing it's job. The schematic and board file plugins expect absolute paths by design. In the past we allowed relative paths which caused all kinds of issues because devs were changing the cwd when saving files to other paths and forgetting to change it back to the project path so we made absolute paths mandatory internally. This is a requirement for developers not users. Users are free to use relative paths, it is the developers responsibility to resolve relative paths before manipulating files. Since this has only been reported in the dev branch and not the stable 5 branch, I suspect code that resolved relative paths to absolute paths accidentally got removed. Please do no remove the assertion.

[Jeff Young (jeyjey)]

@Wayne, ahh, so we're supposed to be converting these but failing (in which case it's just a simple bug, although perhaps not easy to track down).

[Wayne Stambaugh (stambaughw)]

@Jeff, the github project referenced in this bug report should point us
to the faulty path code. I have had a chance to try it out yet.

On 8/27/2018 9:45 AM, Jeff Young wrote:
> @Wayne, ahh, so we're supposed to be converting these but failing (in
> which case it's just a simple bug, although perhaps not easy to track
> down).
>

[Jeff Young (jeyjey)]

Well, this is sort of funny in a perverse sort of way.

The path isn't relative, it just *looks* like it's relative to a Unix system because it doesn't start with a slash:

"C:/Program Files/KiCad/share/kicad/library/Interface_USB.lib"

I've recently fixed a bug where we weren't automatically generating envvar-relative paths in the library tables when adding libraries. But even with that fix someone could still type in a resolved path by hand (or paste it from an Explorer window).

There's not much we can do here as there's no automatic way to know how the given path maps to the Unix machine's filesystem. So I'm just going to put in an error message (with a "don't show again").