inkscape @ 0.92.2_2 all variants: libc++abi.dylib Glib::ConvertError

[streincorp]

On Mac OS X 10.12.6 (Sierra) with Xcode 9.2 regular build and installation

sudo port -ns install inkscape inkscape-textext inkscape-app
--->  Computing dependencies for inkscape
--->  Fetching distfiles for inkscape
--->  Verifying checksums for inkscape
--->  Extracting inkscape
--->  Applying patches to inkscape
--->  Configuring inkscape
--->  Building inkscape
--->  Staging inkscape into destroot
--->  Installing inkscape @0.92.2_2+x11
--->  Activating inkscape @0.92.2_2+x11
--->  Cleaning inkscape
--->  Computing dependencies for inkscape-textext
--->  Fetching distfiles for inkscape-textext
--->  Verifying checksums for inkscape-textext
--->  Extracting inkscape-textext
--->  Configuring inkscape-textext
--->  Building inkscape-textext
--->  Staging inkscape-textext into destroot
--->  Installing inkscape-textext @0.4.4_2+pygtk+python27
--->  Activating inkscape-textext @0.4.4_2+pygtk+python27
--->  Cleaning inkscape-textext
--->  Computing dependencies for inkscape-app
--->  Fetching distfiles for inkscape-app
--->  Verifying checksums for inkscape-app
--->  Extracting inkscape-app
--->  Configuring inkscape-app
--->  Building inkscape-app
--->  Staging inkscape-app into destroot
--->  Installing inkscape-app @0.92_1
--->  Activating inkscape-app @0.92_1
--->  Cleaning inkscape-app

but the command "inkscape" lead to the error

libc++abi.dylib: terminating with uncaught exception of type Glib::ConvertError

Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.

No matter if launched as current user or root, from XQuartz or from the standard Terminal.app

As suggested in ​https://github.com/caskformula/homebrew-caskformula/issues/4#issuecomment-283505030 ,
tried to delete/rename ~/.config/inkscape and ~/.cache/inkscape , no success

As suggested in ​https://github.com/caskformula/homebrew-caskformula/issues/4#issuecomment-343905781
tried to launch:

LANG="en_US.UTF-8" inkscape
LANG="en_US" inkscape
LANG=en_US inkscape
LANG=en_US.UTF-8 inkscape
LANG=C inkscape

with no success.

Tried also to clean/reinstall/compile again with no success

Some hints maybe here: ​https://github.com/caskformula/homebrew-caskformula/issues/41

If the problem is related to the language/locale, mine is

 locale
LANG="it_IT.UTF-8"
LC_COLLATE="it_IT.UTF-8"
LC_CTYPE="it_IT.UTF-8"
LC_MESSAGES="it_IT.UTF-8"
LC_MONETARY="it_IT.UTF-8"
LC_NUMERIC="it_IT.UTF-8"
LC_TIME="it_IT.UTF-8"
LC_ALL=

but also the commands

LANG="it_IT.UTF-8" inkscape
LANG="it_IT" inkscape
LANG=it_IT inkscape
LANG=it_IT.UTF-8 inkscape

lead all to the same error.

Thank you very much for the help and fixes

[dbevans (David B. Evans)]

I've just seen the same issue after upgrading to 0.92.3 on High Sierra 10.13.4 with Xcode 9.3. No answers yet but looking.

[wilya7]

I believe is the same issue I reported here: comment:ticket:52632:30

[Blokkendoos (Johan)]

Same Glib::ConvertError on OS X 10.10.5 with Macports Inkscape.

I have built Inkscape 0.92.3 from source with Debug option and found that the error is related to Glib::ustring usage. Inkscape 0.91 gives the same error, so I assume something changed in Glib? Not being a programmer myself, don't know how to properly fix this, but maybe this info helps.
Cross-posted this info on ​Inkscape Ubuntu One

Regards,
Johan

Details

OS X 10.10.5

Macports: inkscape @0.92.2_2+x11 (active)

glib Macports installed:

dbus-glib @0.110_0 (active) geocode-glib @3.24.0_0 (active) glib-networking @2.54.1_0 (active) glib2 @2.56.0_0+x11 (active) glibmm @2.56.0_0+x11 (active) json-glib @1.2.8_0 (active) taglib @1.11.1_0 (active)

Location of the first occurrence (resulting in ConvertError exception) is in src/widgets/text-toolbar.cpp at line 1792. Workaround using std::string results in the next occurrence at line 1378. And in src/widgets/font-selector.cpp at line 120.

        //Glib::ustring tooltip = Glib::ustring::format(_("Font size"), " (", sp_style_get_css_unit_string(unit), ")");
        std::string tooltip = _("Font size");
        tooltip += " (";
        tooltip += sp_style_get_css_unit_string(unit);
        tooltip += ")";
        ink_comboboxentry_action_set_tooltip ( fontSizeAction, tooltip.c_str());

[neverpanic (Clemens Lang)]

From a quick look, it seems the the thrown Glib::ConvertError means that a character conversion problem has occurred.

The relevant code is in glibmm, ​glib/glibmm/ustring.cc. Our glibmm is configured with GLIBMM_HAVE_WIDE_STREAM, so that already limits the code paths that could be used. I'm not yet sure whether __STDC_ISO_10646__ is defined in our build or whether we are using g_convert.

[neverpanic (Clemens Lang)]

I think the problem may be that iconv is used for character set conversion from a std::wstring's internal memory representation and iconv assumes what the actual encoding is (despite the C++ standard not specifying one). Here's a minimal reproducer:

/* clang++ -std=c++11 -Wall -Werror $(pkg-config --cflags --libs glibmm-2.4) test.cpp -o test */
#include <glibmm.h>
#include <iostream>
#include <string>

int main() {
        std::wstring str = L"Fööööö";
        GError* error = nullptr;
        gsize n_bytes;
        const auto buf = g_convert(reinterpret_cast<const char*>(str.data()), str.size() * sizeof(std::wstring::value_type), "UTF-8", "WCHAR_T", nullptr, &n_bytes, &error);

        if (error) {
                std::cout << error->message << std::endl;
        } else {
                std::cout << buf << std::endl;
        }
}

[neverpanic (Clemens Lang)]

Replacing WCHAR_T with UTF-32LE works, so I guess clang/libc++/libSystem are using that as internal representation for WCHAR_T, while gcc/libstdc++/glibc are using something else.

[neverpanic (Clemens Lang)]

Upstream glibmm related: ​https://bugzilla.gnome.org/show_bug.cgi?id=583992

[streincorp]

@neverpanic I think that should be better to open a separate ticket at gnome.org to track the WCHAR_T crash in glibmm and/or advise the developers of iconv to fix (or reject) WCHAR_T on macOS.

[neverpanic (Clemens Lang)]

Sure, but I have a feeling I'm close to a solution anyway, since I've noticed using the same code that's used for g++/libstdc++ in glibmm also works for clang++/libc++. However, it seems patching the two places in glib/glibmm/ustring.cc are not enough to actually make the crash go away, so I'd still like to do a debug build of inkscape to get a new stacktrace.

If anybody wants to help out with that, that would be welcome. I'm currently not at the machine with the WIP patch, but it doesn't do anything but replacing defined(__STDC_ISO_10646__) with (defined(__STDC_ISO_10646__) || defined(_LIBCPP_VERSION)).

An upstream issue probably gets fixed more quickly with a working patch attached.

[neverpanic (Clemens Lang)]

Got it solved, filed ​https://bugzilla.gnome.org/show_bug.cgi?id=795338 with a patch. Will apply the fix to our copy of glibmm shortly.

[neverpanic (Clemens Lang)]

In e864b2340be9ef003d8ff4aef92e7151d06287dd/macports-ports:

glibmm: Fix character set conversion with libc++

glibmm contains code that attempts to convert between std::wstring and
glibmm's Glib::ustring string class, which stores characters in UTF-8.
This conversion code was using a fallback solution that eventually calls
iconv to convert from the "WCHAR_T" character set to UTF-8.

On macOS, iconv --list does not show WCHAR_T as supported character set
and comments in the libiconv code handling WCHAR_T suggest it was
written for glibc, which is not used on macOS. Consequently, the
conversion failed, which caused Glib::ustring to throw an exception.

This exception was not caught by inkscape and caused a crash when
starting inkscape, rendering it useless.

Fortunately, glibmm already contained code to deal with libc++'s
std::wstrings, but it was guaded by a check for the STDC_ISO_10646
prepocessor define. Allowing _LIBCPP_VERSION in addition to
STDC_ISO_10646 makes code compiled against libc++ use this code path
and solves the issue.

Closes: #56214

[dbevans (David B. Evans)]

Yes, this does the trick, Clemens. Thanks for your help in figuring out and explaining the issues involved,

inkscape updated to latest version 0.92.3 in 605ff8491cd8b43ce5bacdcb5de7c4ad034abfb8/macports-ports