Asserts with component chooser with footprint select dropdown to component chooser

[Nick Østergaard]

I get a bunch of asserts with the new component chooser with footprint select dropdown to component chooser.

I simply open the component chooser and wait for it to be ready.

They appear in the end when I see the new loading bar thingie in the dialog almost finishing, just before it shows the combobox. The mouse cursor is in busy state. See attached for the acutal assert messages.

Application: eeschema
Version: (2017-03-24 revision 68853c988)-master, debug build
Libraries: wxWidgets 3.0.2
           libcurl/7.53.1 OpenSSL/1.0.2k zlib/1.2.11 libpsl/0.17.0 (+libicu/58.2) libssh2/1.8.0
Platform: Linux 4.9.11-1-ARCH x86_64, 64 bit, Little endian, wxGTK
- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.63.0
Curl: 7.53.1
KiCad - Compiler: GCC 6.3.1 with C++ ABI 1010
        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

[Nick Østergaard (nickoe)]

Attached is a backtrace when I break on the line that asserts.

[Chris Pavlina (pavlina-chris)]

Thank god I can repro this. This locale stuff is going to be the death of me.

[Chris Pavlina (pavlina-chris)]

Interesting, this isn't actually in my code - it fails in cvpcb in older builds too. It's definitely a locale issue though. We're casting std::string to wxString instead of using FromUTF8(), which means a string with non-ASCII characters fails conversion (this is all being done in sections forced to C locale).

I'm unassigning myself since I didn't cause this bug. I'll probably end up fixing it, but I'm not promising anything - locale issues like this get complicated. It may be as simple as using the right conversion, or that may break things for people actually running in non-UTF8 locales...

[Chris Pavlina (pavlina-chris)]

It's a bit hard to track this in the debugger. For anyone who wants to take a look, I added the following inside FP_LIB_TABLE::FootprintLoad() in place of the failing assertion:

        //wxASSERT( aFootprintName == (wxString) fpid.GetLibItemName() );
        if( aFootprintName != (wxString) fpid.GetLibItemName() )
        {
            auto loc = wxString( setlocale( LC_ALL, 0 ) );
            auto a = aFootprintName;
            auto b = (wxString) fpid.GetLibItemName();
            auto c = wxString::FromUTF8( fpid.GetLibItemName() );
            bool d = ( a == b );
        }

This allows easy verification of all the values in play. When the assertion fails, the correct name is in "a" and "c", but "b" is an empty string because the conversion failed, so the comparison fails too.

[Chris Pavlina (pavlina-chris)]

This is actually a much deeper encoding-related issue; I'm in conversation with Wayne over the correct way to fix it. Closing this bug since the issue is much broader.

[Wayne Stambaugh (stambaughw)]

@Nick, did commit 4011ed4e fix the assert? I want to be sure we actually fixed the issue.

[Wayne Stambaugh (stambaughw)]

Do we know which library and footprint file(s) triggered this assertion? There may be other places where there could be locale issues so it would be helpful to know for debugging purposes.

[Nick Østergaard (nickoe)]

It looks good, I don't see any asserts with the latest build, 40f60c9871949935f2b4f2f856b04234b2ae3440