Inkscape (GTK+/Quartz) calls all output extensions when quitting while clipboard not empty

Bug #1046068 reported by su_v on 2012-09-04
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

Inkscape built with the quartz backend of GTK+ triggers random output extensions when quitting while data copied in Inkscape is still present on the clipboard.
Confirmed with
- GTK+ 2.24.10 on Mac OS X 10.5.8 (32bit, Intel)
- GTK+ 2.24.11 on OS X 10.7.4 (64bit)

Steps to reproduce:
1) mv ~/.config/inkscape{,-bkp}
2) launch inkscape (empty)
3) draw a rect
4) copy & paste the rect
5) quit Inkscape without saving

Expected result:
Inkscape quits.

Actual result:
- Inkscape
Calls a series of output extensions (e.g. save as XCF, and some UniConvertor-based ones), and finally quits after having closed the dialogs with error messages from failing extensions.
- Inkscape trunk:
crashes immediately (backtrace attached), or opens e.g. PS export options dialog after closing the main window (and crashes when cancelling the export options dialog).

System Info OS X 10.7.4:
Xcode 4.3.2, llvm-gcc-4.2, MacPorts 2.1.2
glib2 2.33.10, glibmm 2.32.1, gtk2 2.24.11, gtkmm 2.24.2

su_v (suv-lp) wrote :
su_v (suv-lp) on 2012-09-04
description: updated
su_v (suv-lp) on 2012-09-04
description: updated
su_v (suv-lp) wrote :

Possibly related to
Bug #418242 “Incorrect call to output plugins (with persistent error message) on copy”

Clayton Walker (clayton.walker) wrote :

Can confirm on OSX 10.7.4.
Built from current bzr source, revno 11675.
Using jhbuild, custom jhbuildrc file, custom inkscape.modules moduleset.
No themes, no fonts.

gtk 2-24 latest git (as of ~ yesterday)
glib 2.33.10

Crashes on exit. Same everything.

su_v (suv-lp) on 2012-09-18
Changed in inkscape:
importance: Undecided → High
status: New → Confirmed
su_v (suv-lp) wrote :

As much as I'd like to raise bug importance to 'Critical', it is not (no loss of data - the document can be saved, the crash occurs after that). It is annoying though, and will certainly be a blocker for releasing OS X packages with the Quartz backend of GTK2/GTK3.

This also affects the usage of the new 'Symbols…' dialog (which copies a symbol to the clipboard as soon as one is selected in the dialog, and consequently triggers the crash when quitting the current session).

su_v (suv-lp) wrote :

Update: possibly fixed upstream in GTK3 (needs further investigation):
- no longer reproduced with experimental Inkscape/GTK3 build (r11878) using GTK3/Quartz 3.6.2, gtkmm 3.6.0
- still reproduced with default Inkscape/GTK2 build (r11878) using GTK2/Quartz 2.24.13, gtkmm 2.24.2
  (GTK+ 2.24.13 compiled with patches from gtk-osx [1] and current git branch [2])

[1] patches for GTK2 copied from stable gtk-osx module set:

[2] my current local GTK2 build (2.24.13) includes patches from git branch up to
5934ad2e22dd04deb823abebeb2815f73522fd5d (from 2012-11-08 14:00:38 (GMT))

su_v (suv-lp) wrote :

Same issue (in stable 0.48.4 and trunk) as described above, with latest GTK+/Quartz 2.24.14 including all patches from git up to most recent clipboard-related fix as described in

Attaching backtrace from trunk r12025 (+ patch for bug #1022543) on OS X 10.7.4.

su_v (suv-lp) wrote :

If this bug is triggered in current stable (0.48.x) inkscape always leaves behind a temp file in $TMPDIR with the clipboard content in SVG format (some of the successfully saved output mime types based on the clipboard content temp file, also written to $TMPDIR, OTOH are cleaned up immediately after creation AFAICT, and failed attempts may result in additional zero-sized temp files).

The crash which now occurs in trunk instead seems to be triggered by the changes for bug #294354:
since likely no more toplevel window is present at that point (Inkscape is crashing on exit, after having closed the document window). An empty (zero-sized) temp file is left behind in $TMPDIR after the crash.
AFAICT the crash occurs as soon as one (or more) output extensions are loaded from the shared or user extensions directory (irrespective of whether the extension itself would produce an error or not) - tested and reproduced by removing all output INX + script files from "$prefix/share/inkscape/extensions" and "$XDG_CONFIG_HOME/inkscape/extensions", and adding back the files for a randomly chosen output file type.

ISTM that Inkscape's system clipboard support needs to be adjusted to better support the (potentially only partially or differently implemented) GtkSelection and GtkClipboard features in the Quartz backend of current GTK+ 2.24.x (to prevent Inkscape from trying to export the clipboard content on exit at all).

su_v (suv-lp) wrote :

With the latest changes in gtk-3-6 (quartz: merge the clipboard storing code from gtk-2-24), experimental GTK3 builds are affected in the same way, and based on the comments in the commit, it seems to be the correct behavior: gtk asks for all targets of the clipboard.

+ /* We simply store all targets into the OS X clipboard. We should be
+ * using the functions gdk_display_supports_clipboard_persistence() and
+ * gdk_display_store_clipboard(), but since for OS X the clipboard support
+ * was implemented in GTK+ and not through GdkSelections, we do it this
+ * way. Doing this properly could be worthwhile to implement in the future.
+ */

Possibly related: the most recent discussion in

For Inkscape, a current solution could be to:
1) silently fail if export to clipboard fails (don't show the error messages returned by some of the output extensions)
2) in trunk: do not try to modify the window title bar when exporting the clipboard content (there is no window to be modified)

jazzynico (jazzynico) wrote :

Not reproduced on Windows XP, Inkscape trunk revision 10923, 11098 and 12068.

Would you be willing to test the attached patch? It just adds a test on the existence of the desktop. I'm not sure it is absolutely necessary here, but who knows.

su_v (suv-lp) wrote :

> Not reproduced on Windows XP, Inkscape trunk revision 10923, 11098 and 12068.

AFAICT Inkscape builds with the X11- and win32-backend of GTK+ are not affected (since they don't need to export the clipboard content to all supported output formats on quit: no one expects the copied selection to be available after the application has quit). I have applied the same patch to the X11-based trunk builds as well, and will watch out for any unexpected side-effects.

> Would you be willing to test the attached patch?

Patch tests ok with GTK+/Quartz 2.24.14 - what a relieve :-) (even if only using the trunk builds for testing mostly, and not any production work). Downside is that now I have to close several popups from output extensions complaining about missing layers (the clipboard content from Inkscape does not store layer information), and patiently wait until these (IMHO for most parts useless) exports have finished. But that's not related to the crash (and also happens with stable versions).

jazzynico (jazzynico) wrote :

Crash fixed in the trunk, revision 12071 (patch also tested on Windows XP and Debian testing, no regression found).

Changed in inkscape:
status: Confirmed → Triaged
su_v (suv-lp) on 2014-01-27
tags: removed: crash
summary: - Inkscape (GTK+/Quartz) calls output extensions or crashes when quitting
- while clipboard not empty
+ Inkscape (GTK+/Quartz) calls all output extensions when quitting while
+ clipboard not empty
Changed in inkscape:
importance: High → Medium
su_v (suv-lp) wrote :

I'm tempted to either mark this as blocker, or at least to raise importance again: this is a showstopper for releasing a quartz-based package for Mac OS X, and it seems to get worse over time (recent changes to extensions now may trigger even more errors - with current trunk I have to close 10 (!) error messages from output extensions when quitting inkscape after simply having inserted a symbol (from the symbols dialog) into a new document before quitting).

Possible solutions:
a) script-based output extensions need to fail _silently_ when processing the clipboard content on request (e.g. from GTK+),
or (alternatively):
b) do not support the idea of a persistent clipboard and never attempt to output the current clipboard content to _all_ supported file formats on quitting the application (ignore any requests).

su_v (suv-lp) wrote :

Proposed partial workaround:

It adds errormsg() to the Effect class, so that the function can check the content of the current document for the presence of <inkscape:clipboard> node (an indicator that the document contains the SVG content exported earlier to the clipboard).

su_v (suv-lp) wrote :

Attached is a list of backtraces reported back on application quit from extensions which fail to process the clipboard content which holds a single <symbol> element (after dragging it into canvas from the 'Symbols' dialog). These type of error messages are not caught by the workaround described in the prior comment.

su_v (suv-lp) wrote :

Attached: the SVG file in $TMPDIR with the clipboard content which triggers the script failures.

su_v (suv-lp) wrote :

Attached: another SVG file in $TMPDIR with clipboard content which doesn't trigger the same script failures.
Content: a rectangle with its original default style.

su_v (suv-lp) wrote :

Ideally, it would be nice to be able to suppress the error messages internally, similar to how it is done for command line usage:

    Glib::ustring stderr_data = fileerr.string();
    if (stderr_data.length() != 0 &&
       ) {
        checkStderr(stderr_data, Gtk::MESSAGE_INFO,
                                 _("Inkscape has received additional data from the script executed. "
                                   "The script did not return an error, but this may indicate the results will not be as expected."));

Such a solution might also be helpful to prevent bug #418242 from interrupting workflows on linux.

Alvin Penner (apenner) wrote :

I guess my first question would be, how did this data get into the clipboard in the first place? It seems that most of the errors are related to the fact that the clipboard data does not have 'width' and 'height' attributes. If default values of these attributes could be added to the clipboard data when it was originally generated, then maybe the problem would be solved at the source. Solving it in the Python extensions is going to be very messy.

su_v (suv-lp) wrote :

> how did this data get into the clipboard in the first place?

As described on comment #14: drag&drop of symbols from the 'Object > Symbols' dialog is done via clipboard internally.

See also:

To me it is a legitimate request that output extensions deal with inkscape clipboard content without failure - whether or not the clipboard data for a <symbol> element actually would need to (or never should) have fixed 'width' and 'height' attributes is beyond the scope of this report.

su_v (suv-lp) wrote :

Attached is a quick hack to stop the known error messages if width and/or height attributes are missing (quick hack, depends on diff from comment #13 which supplies a new 'errormsg()' function that checks whether the output parses an SVG file based on the clipboard content).

Missing: stop UniConvertor failure messages from being reported back if clipboard content is parsed ( is already imported in '' - it would be possible to init the effect with the doc, but one would first need to extract the path to the document first from 'command_format' AFAIU)

su_v (suv-lp) wrote :

New version - missed testing with gimp installed (in $PATH) - also fails to get page width/height... this is really getting messy :(

su_v (suv-lp) on 2014-10-21
Changed in inkscape:
milestone: none → 0.92
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.

Other bug subscribers

Remote bug watches

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