Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#56214 closed defect (fixed)

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

Reported by: streincorp Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version: 2.4.2
Keywords: Cc: Blokkendoos (Johan)
Port: inkscape


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
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

As suggested in ,
tried to delete/rename ~/.config/inkscape and ~/.cache/inkscape , no success

As suggested in
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:

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


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

Change History (13)

comment:1 Changed 3 years ago by mf2k (Frank Schima)

Cc: dbevans removed
Owner: set to dbevans
Port: @0.92.2_2 removed
Status: newassigned

comment:2 Changed 3 years ago by dbevans (David B. Evans)

Status: assignedaccepted

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.

comment:3 Changed 3 years ago by wilya7

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

Last edited 3 years ago by ryandesign (Ryan Schmidt) (previous) (diff)

comment:4 Changed 3 years ago by Blokkendoos (Johan)

Cc: Blokkendoos added

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



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());
Last edited 3 years ago by Blokkendoos (Johan) (previous) (diff)

comment:5 Changed 3 years ago by 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/ 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.

comment:6 Changed 3 years ago by 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.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;

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by neverpanic (Clemens Lang)

comment:9 Changed 3 years ago by streincorp

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

comment:10 Changed 3 years ago by 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/ 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.

Last edited 3 years ago by neverpanic (Clemens Lang) (previous) (diff)

comment:11 Changed 3 years ago by neverpanic (Clemens Lang)

Got it solved, filed with a patch. Will apply the fix to our copy of glibmm shortly.

comment:12 Changed 3 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: acceptedclosed

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

comment:13 Changed 3 years ago by 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

Note: See TracTickets for help on using tickets.