Inkscape aqua crashes on using "save as..."

Bug #721448 reported by Gellule on 2011-02-18
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

I'm compiling inkscape aqua using macports. I'm using variants +aqua +no_x11, and also goes around the issue described in I then end-up with an executable that seems to be working fine, until I try to save something to disk, using "save as...". A few tests:
When using "save" directly, all is fine, but as soon as I try to exit from the "save as..." GUI, with save or cancel, I get the following crash:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff863d5120 in objc_msgSend ()
(gdb) bt
#0 0x00007fff863d5120 in objc_msgSend ()
#1 0x00007fff88039504 in _DPSNextEvent ()
#2 0x00007fff880387a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#3 0x0000000101e05fcd in poll_func ()
#4 0x00000001022a8fa8 in g_main_context_iterate ()
#5 0x00000001022a92a5 in g_main_loop_run ()
#6 0x0000000101a029f0 in gtk_main ()
#7 0x00000001000306b0 in sp_main_gui ()
#8 0x000000010002fd2e in main ()

su_v (suv-lp) on 2011-02-18
tags: added: crash gtk-osx saving
Changed in inkscape:
importance: Undecided → High
su_v (suv-lp) wrote :

Could you provide details about your platform (OS X version, arch)?

Also, it would be helpful to add the versions of the main dependencies (like gtk+, glib, gtkmm and glibmm) used for your current build to the report (as MacPorts updates quite frequently and things might change with later versions).

Gellule (gellule-xg) wrote :

As requested:
OS X 10.6.6, intel
gtk2 @2.22.1
gtkmm @2.22.0
glib2 @2.26.1
glibmm @2.24.2

Gellule (gellule-xg) wrote :

It seems related to the 'save bug' described in the following thread:
The crash report attached to that thread has the exact same backtrace.

Gellule (gellule-xg) wrote :

I turned GDK_WINDOWING_QUARTZ off and it seems that I am able to go past this bug, to reach a next bug:

su_v (suv-lp) wrote :

Reproduced with Inkscape 0.48+devel r10101 on OS X 10.5.8 (i386), gtk2 @2.22.1_1+no_x11+quartz

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x696c7582
0x9254b818 in objc_msgSend_fpret ()
(gdb) bt
#0 0x9254b818 in objc_msgSend_fpret ()
#1 0x92dd9dcf in _DPSNextEvent ()
#2 0x92dd8f88 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#3 0x0246b457 in poll_func ()
#4 0x02f1642f in g_main_context_iterate ()
#5 0x02f16887 in g_main_loop_run ()
#6 0x017a6e71 in gtk_main ()
#7 0x011bcd4b in Gtk::Main::run ()
#8 0x00004e6c in ~vector [inlined] () at stl_vector.h:986
#9 sp_main_gui (argc=1, argv=0xbffff3a8) at main.cpp:993
#10 0x00003a66 in start ()
(gdb) quit

Changed in inkscape:
status: New → Confirmed
su_v (suv-lp) wrote :

Raising bug status to 'Critical' - this is a major blocker IMHO for GTK+/Quartz based Inkscape ports to Mac OS X. Please revert if you don't agree.

Changed in inkscape:
importance: High → Critical
su_v (suv-lp) wrote :

> I turned GDK_WINDOWING_QUARTZ off and it
> seems that I am able to go past this bug,

Would you be willing to share details or attach diffs so that others can test the same set of changes (without having to do (duplicate) research about it)?

su_v (suv-lp) wrote :

The crash is only triggered when using the commands from the menubar: using the keyboard shortcuts ('Shift+Ctrl+S' "Save as…", 'Shift+Ctrl+Cmd+S' "Save a copy as…') works as expected and without crash.
(tested with unchanged build r10101 (no local patches) using @2.22.1_1+no_x11+quartz)

Unexpectedly, the key 'Cmd' acts the same as 'Alt' under X11, whereas the real 'option/alt' key doesn't seem to be recognized by Inkscape.

Changed in inkscape:
status: Confirmed → Triaged
Gellule (gellule-xg) wrote :

Sure can, but it may take a little while. I have a few other modifications in a local branch I need to clean up and then share.

Gellule (gellule-xg) wrote :

Here is the patch to remove all trace of mac integration.

su_v (suv-lp) wrote :

Ah, that's the "brut force" way ;)
I had hoped that you had figured out the crucial point (or file) to undef GDK_WINDOWING_QUARTZ, since all (or most of the) relevant code seems to be within

Gellule (gellule-xg) wrote :

From there, I think I would like to try to get integration back from ige-mac-integration. [1]

There is GtkOSXApplication for x86_64, and ige-mac-integration for the others.

[1] <>

su_v (suv-lp) on 2011-03-21
tags: added: osx
Gellule (gellule-xg) on 2011-06-16
Changed in inkscape:
assignee: nobody → Gellule (gellule-xg)
Roy Liu (royliu) wrote :

Ok, I made some progress on this bug. See attached patch menus.diff -- it's a big one. Here's what I did, with substeps:
1. Changed the ige-mac-integration dependency to gtk-mac-integration.
       1. As a prerequisite, added gtk-mac-integration as a pkg-config definition on
       2. Removed old ige-mac-integration code completely, as Inkscape +quartz now requires the libgtkmacintegration to build.
2. Changed the menu integration code to reflect the new dependencies.
      1. Moved the integration code from interface.cpp to desktop-widget.cpp.
      2. Added some extra code to conforms to the new dependency on gtk-osx-application (a subcomponent of gtk-mac-integration).

This patch is applicable on Inkscape 0.48.2. Those who are interested in trying it out in MacPorts are welcome to contact me for help.

su_v (suv-lp) wrote :

> This patch is applicable on Inkscape 0.48.2

Apparently the diff is against the sources from the tar ball release (as used in MacPorts) and doesn't apply to a checkout of the sources from bzr … any chance you could provide a patch against current trunk (lp:inkscape)? Note that there have been many changes in trunk (for 0.49) which will never be backported to 0.48.x.

Any limitations with regard to switching to 'gtk-mac-integration' (e.g. support of building on Mac OS X 10.5.8)?

su_v (suv-lp) wrote :

@Roy Liu - many thanks for working on this!

Initial notes on testing the patch with Inkscape 0.48.2 (patched and installed via MacPorts [1]) on Mac OS X 10.5.8 (i386):
+ dynamic submenus are back - that's great news :)
+ no crashes so far when using the menu commands to open dialogs or other documents
+ …

- opening additional document windows duplicates the menubar entries (screenshot attached)
- after closing a new window, one of the duplicate menubars is removed, but the other menus no longer work (or not consistently)
- no keyboard shortcuts displayed in the menus
- many warnings about manu accelerators:
  GLib-GObject-WARNING **: g_object_get_valist: object class `GtkLabel' has no property named `accel-closure'
- …

[1] 0.48.2 built ok after I figured out that the linker flag '-lX11' needs to be removed not only from 'configure' but from '' as well ;) (apparently, menus.diff triggers a regeneration of configure on 'make', based on '' which still includes the '-lX11' linker flags in INKSCAPE_LIBS)

su_v (suv-lp) wrote :
su_v (suv-lp) wrote :

Inkscape 0.48.2 + patch (menus.diff) cont.:
- menu 'File > Open Recent' opens the first file no matter which file
  was selected from the list - the same problem also occurs with the
  global menu on Ubuntu /Unity:

Regressions with GTK+ 2.24.7 (not seen in earlier GTK+ dot releases,
not related to the menubar integration):
- GTK+ Fullscreen mode fails (menu 'View > Fullscreen)
  the application window as well as the menu bar simply disappear
- Function keys no longer work for keyboard shortcuts
  (e.g. once fullscreen mode has been entered and the window disappears,
  there is no way to return to normal state except by killing inkscape)

Roy Liu (royliu) wrote :


Thank you for your reply. There are still some issues to be addressed:
1. I am aware of the "accel-closure" problem. I'm not an expert on GTK, but I think it has something to do with changes in quartz keyboard acceleration. This is probably also related to having no keyboard shortcuts displayed.
2. I know why you're getting menubar duplicates. Putting extra code in desktop-widget.cpp was the wrong choice, because those desktop widgets aren't unique. Every time one is created, the code I inserted gets duplicated.
3. Sometimes Inkscape crashes on startup. Perhaps you can reproduce this by trying to restart it repeatedly?
4. The patch is on top of 0.48.2.
5. Do you know of an in-house GTK expert I can ask?


Roy Liu (royliu) wrote :

Does this patch make the duplicates problem go away?

su_v (suv-lp) wrote :

> Does this patch make the duplicates problem go away?

Yes, no more duplicate menu bars… thx

I do get reproducible crashes though:

1) launch inkscape
2) open second document window (I used the first button on the commands bar)
3) close second window (I used the close button of the window decoration)
4) change view mode to 'Outline' in the remaining (first) document window
   (menu 'View > Display mode > Outline')

-> crash

The crash does not occur when changing view mode in the second window, nor when changing it in the first window before opening and closing the second window.

Backtrace attached (Inkscape was compiled with newly installed gtk2 2.24.8).

Minor issue I noticed with the 'Display mode' submenu: it does not update the currently used view mode after changing it.

su_v (suv-lp) wrote :

Another crash also related to opening/closing a second window:

1) launch Inkscape, open an existing file
2) open new document, close it again
3) modify the file opened in step 1
4) use 'File > Revert' to revert to the saved version

-> crash

'File > Revert' works fine if no second document window had been opened and closed.

We should probably better use a separate (new) bug report to track issues with the proposed patch to use 'gtk-osx-application' from 'gtk-mac-integration' instead of the outdated 'ige-mac-menu.*' files (or no integration at all).

As it stands, the current version of Inkscape crashes with it's current Mac OSX menu-bar integration.
Therefore, unless you've memorized the keystrokes, or have remove the integration code yourself, Inkscape will crash.

Can we apply the no_integration patch for now, and leave the re-integration with the newer code for later?

su_v (suv-lp) wrote :

> Can we apply the no_integration patch for now (…)

Attaching updated 'patch-nointegration.diff' (see comment #10) against current trunk r10946
(the old patch no longer works - 2 hunks fail).

> (…) and leave the re-integration with the newer code for later?

Personally I would agree (though it takes off pressure to get it fixed properly, i.e. migrating to gtk-mac-integration and gtk-osx-application) - quartz-based builds are a pain to test without having removed the old and broken code.

I have been using the patch for months now with quartz-based test builds from trunk on Mac OS X 10.5.8 (i386) (Apple GCC 4.2.1), and as far as I can tell it does not affect building on other platforms with different gtk backends (tested with r10946 and GTK+/X11 2.24.9 on OS X Lion, one build using Apple llvm-gcc-4.2, another one with FSF GCC 4.6.2).

su_v (suv-lp) wrote :

If removing the old ige-mac-menu.* stuff gets agreed on, I would urge to backport it to the 0.48.x branch as well, see also Inkscape bug #721424 and related trac tickets in MacPorts:

Linker flags:

Crashes due to broken menu integration code:
<> (comment #2)

su_v (suv-lp) wrote :

Patch from comment #23 also tested with of Inkscape 0.48+devel r10946 and r10947 on
- Mac OS X 10.45.8 Leopard (i386), GTK+/X11 2.24.8, Apple GCC 4.2.1
(build succeeds without failure, and application runs fine)

su_v (suv-lp) wrote :

Patch backported to 0.48.x branch,
tested ok with Inkscape 0.48.x r9865:

1) normal build (no special configure options)
- OS X 10.7.2 Lion 64bit, GTK+/X11 2.24.9, Apple llvm-gcc-4.2

2) configured with --enable-osxapp, and packaged as
    (requires local backport of trunk changes for packaging script)
- Mac OS X 10.5.8 Leopard (i386), GTK+/X11 2.24.4, Apple GCC 4.2.1,
- Mac OS X 10.5.8 Leopard (i386), GTK+/Quartz 2.24.8, Apple GCC 4.2.1,

su_v (suv-lp) wrote :

@SislaC - based on my tests, the patches should be save for trunk as well as for the 0.48.x branch:
- it works with Quartz-based builds (trunk, stable)
- it does not affect X11-based builds on OS X (trunk, stable)

I could not verify the changes to 'CMakeLists.txt' myself - AFAIK cmake is broken in the 0.48.x branch anyway, and in trunk the change removes the reference to the two deleted files (src/ige-mac-menu.c, src/ige-mac-menu.h).

tags: added: backport-proposed
su_v (suv-lp) wrote :

Setting target 0.48.3 - backporting to 0.48.x would allow to have more stable Quartz-based builds on Mac OS X (albeit without using the global menu bar). See also comment #23-24.

Changed in inkscape:
milestone: none → 0.48.3
ScislaC (scislac) wrote :

Was the patch based on Roy Liu's work what we ended up using? I just want to make sure we get the right person assigned.

Changed in inkscape:
status: Triaged → Fix Committed
su_v (suv-lp) wrote :

ScislaC wrote:
> Was the patch based on Roy Liu's work what we ended up using?

No (not yet) - the patch to remove the old code for the menu integration was originally done by Gellule (see comment #10).

Hopefully Roy Liu's work can be picked up to implement full support of the global menu bar based on gtk-mac-integration and gtk-osx-application.

su_v (suv-lp) on 2012-02-08
tags: removed: backport-proposed
Roy Liu (royliu) wrote :

Sorry for being silent for so long. The patch to remove Mac OS X menu integration looks good. That way any changes I make to *add* menu integration will look clearer. I wish I knew more GTK and had more time, but I'll try to invest more time into this over the coming months. Would appreciate some help in understanding how GTK is architected, especially gtk-mac-integration.

Ted Gould (ted) on 2012-02-15
Changed in inkscape:
status: Fix Committed → Fix Released
su_v (suv-lp) on 2017-01-12
tags: added: gtk-quartz
removed: gtk-osx
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.